Skip to content

Conversation

Elinvynia
Copy link
Contributor

Cherry picked:

r? @ghost

estebank and others added 4 commits July 6, 2020 08:00
Fix a crash when searching for an alias contained in the currently selected filter crate. Also remove alias search results for crates that should be filtered out. The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.
This commit intends to fix an accidental regression from #70846. The goal of #70846 was to build compiler-builtins with a maximal number of CGUs to ensure that each module in the source corresponds to an object file. This high degree of control for compiler-builtins is desirable to ensure that there's at most one exported symbol per CGU, ideally enabling compiler-builtins to not conflict with the system libgcc as often. In #70846, however, only part of the compiler understands that compiler-builtins is built with many CGUs. The rest of the compiler thinks it's building with `sess.codegen_units()`. Notably the calculation of `sess.lto()` consults `sess.codegen_units()`, which when there's only one CGU it disables ThinLTO. This means that compiler-builtins is built without ThinLTO, which is quite harmful to performance! This is the root of the cause from #73135 where intrinsics were found to not be inlining trivial functions. The fix applied in this commit is to remove the special-casing of compiler-builtins in the compiler. Instead the build system is now responsible for special-casing compiler-builtins. It doesn't know exactly how many CGUs will be needed but it passes a large number that is assumed to be much greater than the number of source-level modules needed. After reading the various locations in the compiler source, this seemed like the best solution rather than adding more and more special casing in the compiler for compiler-builtins. Closes #73135
@Elinvynia
Copy link
Contributor Author

Hmm the error seems to related to #73596

cc @petrochenkov

@mati865
Copy link
Member

mati865 commented Jul 6, 2020

@Elinvynia #73136 was accepted in previous version, 926c7b6 to be exact. That's because master committed version might not work with older Cargo.

As per #73184 (comment) #73184 was also accepted but it's missing the label.

@Mark-Simulacrum Mark-Simulacrum mentioned this pull request Jul 10, 2020
@Mark-Simulacrum
Copy link
Member

Closing in favor of #74219, which contains a few more PRs. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

7 participants