-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Set PrepareForThinLTO flag when using ThinLTO #50684
Conversation
The LLVM PassManager has a PrepareForThinLTO flag, which is intended when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes, which ensures that all globals have a name. * In optimized builds, a number of late passes (mainly related to vectorization and unrolling) are disabled, on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in rust-lang#49479, which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs, this might have performance (or other) impact, so we want to land this separately.
(rust_highfive has picked a reviewer for you, use r? to override) |
@bors r+ |
📌 Commit a70ef4c has been approved by |
Would it be possible to also get a perf run for this? |
Once it lands we'll get perf from that, we can run perf separately too, though. @bors try |
Set PrepareForThinLTO flag when using ThinLTO The LLVM PassManager has a PrepareForThinLTO flag, which is intended for use when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes, which ensures that all globals have a name. * In optimized builds, a number of late passes (mainly related to vectorization and unrolling) are disabled, on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479, which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs, this might have performance (or other) impact, so we want to land this separately.
☀️ Test successful - status-travis |
Set PrepareForThinLTO flag when using ThinLTO The LLVM PassManager has a PrepareForThinLTO flag, which is intended for use when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes, which ensures that all globals have a name. * In optimized builds, a number of late passes (mainly related to vectorization and unrolling) are disabled, on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479, which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs, this might have performance (or other) impact, so we want to land this separately.
☀️ Test successful - status-appveyor, status-travis |
Looks like small improvements to non-incremental optimized builds across most crates. Hopefully no corresponding runtime regressions... |
Those improvements are nothing to sneeze at, pretty sure the Gecko people will be happy about this. |
The LLVM PassManager has a PrepareForThinLTO flag, which is intended for use when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects:
This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used.
The background for this change is the CI failure in #49479, which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs, this might have performance (or other) impact, so we want to land this separately.