Faster compile times for release builds with small fix

[andjo403]

Was looking at the printout of llvm passes when I noticed that the functions that was inlined everywhere, and due to this was dead code, was optimized more after inlining.

So as a test I added MPM.add(createGlobalDCEPass()); at the line PassManagerBuilder.cpp#L480 and this reduces the compile time of release build in racer by an average of 23%.

I do not know if this is a good place to add this extra pass but maybe someone that knows how llvm works can use this information to speedup the compilation of release builds.

was also wondering how this works in MIR I see that there is an inline pass but I can not find any dead code elimination

[andjo403]

the stage1 compilation of rustc went from 828.89 to 691.75 secs with this fix on my computer but that is only a 15% improvement

[oyvindln]

15% is pretty significant.

[jonas-schievink]

Wow, great work!

[TimNN]

@andjo403: That's some nice improvements! If you feel up to it, go ahead an submit a pull request with your suggested changes. That way someone with experience with LLVM is guaranteed to look at the patch and it won't get lost.

[leoyvens]

I believe the PR should be targeted at https://github.com/rust-lang/llvm.

[TimNN]

@leodasvacas: 👍

@andjo403: If you want to push through this patch the general process works like this:

• Submit the patch against the currently active branch of rust-lang/llvm (which is rust-llvm-release-4-0-1 at the moment)
• Wait for it to get reviewed & merged
• Submit a pull request against rust-lang/rust which updates the src/llvm submodule.

If you have any questions about the process or want someone else to do this, just mention it here or contact me or someone else on one of the Rust IRC channels.

[Mark-Simulacrum]

cc @arielb1

[nagisa]

cc #33299

[cuviper]

Ideally, the process should include discussion with upstream LLVM too.

[andjo403]

llvm ticket

[alexcrichton]

Unfortunately it looks like we were a bit too eager to close this in #45054 :(

[andjo403]

From what I have learned from the llvm maintainers I think that we have received the improvement that can be expected. The to good to be true improvements I measured was probably due to less optimizations was possible and resulted in less optimized code.