Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[beta] Backport #74085

Closed
wants to merge 4 commits into from
Closed

[beta] Backport #74085

wants to merge 4 commits into from

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
Contributor

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants