Reenable the MergeFunctions pass

[nox]

The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc
pass enabled and it hugely reduces code size (for example it shaves off 10% of the
final Servo executable). This patch reenables it.

For those wondering, here are the docs from LLVM about this pass.

[nox]

…Aaaand I forgot the obvious: @rust-lang/wg-codegen

[oli-obk]

remove this outdated comment, too?

[nox]

Oh yes… I'll wait for the try to finish and do the amend.

[nagisa]

Please do a crater run.

…

On Thu, Mar 29, 2018, 13:43 Oliver Schneider ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/rustllvm/PassWrapper.cpp <#49479 (comment)>: > @@ -431,7 +431,7 @@ extern "C" void LLVMRustConfigurePassManagerBuilder( bool MergeFunctions, bool SLPVectorize, bool LoopVectorize, const char* PGOGenPath, const char* PGOUsePath) { // Ignore mergefunc for now as enabling it causes crashes. remove this outdated comment, too? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#49479 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0tt4acwAKZF7dk3OAZZdbleuyKNXks5tjMjxgaJpZM4TALT-> .

[nagisa]

r=me when/if that passes.

…

On Thu, Mar 29, 2018, 14:06 Simonas Kazlauskas ***@***.***> wrote: Please do a crater run. On Thu, Mar 29, 2018, 13:43 Oliver Schneider ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In src/rustllvm/PassWrapper.cpp > <#49479 (comment)>: > > > @@ -431,7 +431,7 @@ extern "C" void LLVMRustConfigurePassManagerBuilder( > bool MergeFunctions, bool SLPVectorize, bool LoopVectorize, > const char* PGOGenPath, const char* PGOUsePath) { > // Ignore mergefunc for now as enabling it causes crashes. > > remove this outdated comment, too? > > — > You are receiving this because you are on a team that was mentioned. > Reply to this email directly, view it on GitHub > <#49479 (review)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AApc0tt4acwAKZF7dk3OAZZdbleuyKNXks5tjMjxgaJpZM4TALT-> > . >

[nagisa]

cc @rust-lang/infra for the crater run. I know there’s a bot for this, but no idea what the bot is :)

[kennytm]

@bors try

There's no bot running yet, all manual 🙃

[bors]

⌛️ Trying commit 84135bf with merge 0dc6a34...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[nox]

I removed the obsolete comment.

[aidanhs]

Crater run started.

[aidanhs]

(apologies for the delay, I fell ill last week)

Hi @nagisa (crater requester), @alexcrichton (PR reviewer)! Crater results are at: http://cargobomb-reports.s3.amazonaws.com/pr-49479/index.html. 'Blacklisted' crates (spurious failures etc) can be found here. If you see any spurious failures not on the list, please make a PR against that file.

(interested observers: Crater is a tool for testing the impact of changes on the crates.io ecosystem. You can find out more at the repo if you're curious)

[nox]

@nagisa None of those regressions seem related to the PR. Am I wrong about that?

[nox]

Actually as @aidanhs points out on IRC, the addr2line 0.5.0 failure is probably related:

Apr 01 16:15:13.014 INFO blam! ---- identity_map stdout ----
Apr 01 16:15:13.014 INFO blam! 	we missed 0x00254c40: (Some("dwarf.c"), None)
Apr 01 16:15:13.014 INFO blam! we missed 0x0024de20: (Some("elf.c"), None)
Apr 01 16:15:13.014 INFO blam! we missed 0x00018320: (Some("crtstuff.c"), None)
Apr 01 16:15:13.014 INFO blam! we missed 0x00252db0: (Some("dwarf.c"), None)
Apr 01 16:15:13.014 INFO blam! thread 'identity_map' panicked at 'assertion failed: `(left == right)`
Apr 01 16:15:13.014 INFO blam!   left: `(Some("/checkout/src/liballoc_jemalloc/../jemalloc/src/prof.c"), Some(2164))`,
Apr 01 16:15:13.014 INFO blam!  right: `(Some("/checkout/src/liballoc_jemalloc/../jemalloc/src/prof.c"), Some(1984))`', tests/integration_test.rs:61:13

That test checks some symbols from the test executable itself, which makes me believe that the discrepancy with the system addr2line tool comes from MergeFunctions doing its job.

Given the executable manages to run (barring the test failure), this can mean various things:

• MergeFunctions is breaking the executable in a way that the test manages to run and fail;
• we didn't account for MergeFunctions doing its job in debuginfo stuff;
• addr2line 0.5.0 has a bug and MergeFunctions running made it apparent;
• none of the above and I'm out of clue.

[nox]

Also tasks-framework 0.1.0:

Apr 04 07:47:17.638 INFO blam! test actor_runner_schedule_with_a_primitive_actor_and_a_threadpool_executes_correctly ... FAILED
Apr 04 07:47:17.638 INFO blam! 
Apr 04 07:47:17.638 INFO blam! failures:
Apr 04 07:47:17.638 INFO blam! 
Apr 04 07:47:17.638 INFO blam! ---- actor_runner_schedule_with_a_primitive_actor_and_a_threadpool_executes_correctly stdout ----
Apr 04 07:47:17.638 INFO blam! 	thread 'actor_runner_schedule_with_a_primitive_actor_and_a_threadpool_executes_correctly' panicked at 'assertion failed: `(left == right)`
Apr 04 07:47:17.638 INFO blam!   left: `9995`,
Apr 04 07:47:17.638 INFO blam!  right: `10000`', tests/single_queue_actor.rs:47:5

I'll try to reproduce that locally, though I'm not on Linux.

[nagisa]

The glib-0.5.0, nanopow-rs-0.3.3, simple-signal-1.1.1 timeouts seem scary.

pushover-0.3.0 seems to be in the same bucket as tasks-framework in that it seems to return a wrong result?

[nox]

@nagisa I guess I can't read cargobomb reports correctly, hah! I'll run all of that on macOS and see what I can reproduce during next week.

[aidanhs]

I've seen glib and nanopow timeouts in recent memory on other crater runs so wouldn't worry about those.

[pietroalbini]

Ping from triage! The crater run on this is now complete, how should we move forward?

[nagisa]

This is pending review of issues by @nox. I believe they couldn’t reproduce issues on OS X and were going to try to reproduce on a Linux box.

[Eijebong]

So I tried reproducing those failures on a linux machine.

	nightly	mergefunc	comment
addr2line	X	X	Ran into #49942
borrow-bag	V	V
glib	V	V
nanopow	V	V
net-utils	V	V
pushover	X	X	Fails on nightly with the same failure as the crater one
serenity	V	V
simple-signal	V	V
rust-tasks	V	V
verilog	V	V

X: Build or tests failed
V: Tests passed

I also tried the build on some unreleased projects I have, it brought the size down from 2.3MB to 1.5MB 😍

[nox]

So… LGTM?

[nox]

I amended the second commit with an #if LLVM_RUSTLLVM check.

[nagisa]

@bors r+

[bors]

📌 Commit 5701779 has been approved by nagisa

[bors]

⌛️ Testing commit 5701779 with merge b92f6a9...

[bors]

💔 Test failed - status-travis

[rust-highfive]

The job i686-gnu of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:15:11] [ 89%] Building CXX object tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o
[00:15:11] [ 89%] Building CXX object tools/lto/CMakeFiles/LTO.dir/lto.cpp.o
[00:15:11] [ 89%] Linking CXX executable ../../bin/llvm-config
[00:15:12] [ 89%] Linking CXX executable ../../bin/llvm-ar
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[rust-highfive]

The job i686-gnu of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:15:11] [ 89%] Building CXX object tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o
[00:15:11] [ 89%] Building CXX object tools/lto/CMakeFiles/LTO.dir/lto.cpp.o
[00:15:11] [ 89%] Linking CXX executable ../../bin/llvm-config
[00:15:12] [ 89%] Linking CXX executable ../../bin/llvm-ar
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[pietroalbini]

Timeout building LLVM.

@bors retry

[kennytm]

@bors p=12

[bors]

⌛️ Testing commit 5701779 with merge e1151c9...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nagisa
Pushing e1151c9 to master...

[nikic]

FTR llvm-mirror/llvm@be07815 and llvm-mirror/llvm@63bcfe3 will be part of LLVM 6.0.1, at which point this could work with system llvm as well.