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

Set PrepareForThinLTO flag when using ThinLTO #50684

Merged
merged 1 commit into from
May 12, 2018

Conversation

nikic
Copy link
Contributor

@nikic nikic commented May 12, 2018

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.

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
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 12, 2018
@nagisa
Copy link
Member

nagisa commented May 12, 2018

@bors r+

@bors
Copy link
Contributor

bors commented May 12, 2018

📌 Commit a70ef4c has been approved by nagisa

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 12, 2018
@nikic
Copy link
Contributor Author

nikic commented May 12, 2018

Would it be possible to also get a perf run for this?

@Mark-Simulacrum
Copy link
Member

Once it lands we'll get perf from that, we can run perf separately too, though. @bors try

@bors
Copy link
Contributor

bors commented May 12, 2018

⌛ Trying commit a70ef4c with merge 7c58a5f...

bors added a commit that referenced this pull request May 12, 2018
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.
@bors
Copy link
Contributor

bors commented May 12, 2018

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

@bors
Copy link
Contributor

bors commented May 12, 2018

⌛ Testing commit a70ef4c with merge c0cea75...

bors added a commit that referenced this pull request May 12, 2018
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.
@bors
Copy link
Contributor

bors commented May 12, 2018

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

@bors bors merged commit a70ef4c into rust-lang:master May 12, 2018
@nikic
Copy link
Contributor Author

nikic commented May 12, 2018

Perf results: http://perf.rust-lang.org/compare.html?start=e6db79f2ca07e4e533f4e940462a42f1093e52f3&end=c0cea750a0a10a0ed5a101839e37968d87f8ef9d&stat=instructions%3Au

Looks like small improvements to non-incremental optimized builds across most crates. Hopefully no corresponding runtime regressions...

@nox
Copy link
Contributor

nox commented May 12, 2018

Those improvements are nothing to sneeze at, pretty sure the Gecko people will be happy about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants