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.

Sign up for GitHub

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

Jump to bottom

Use module inline assembly to embed bitcode #91654

Merged
merged 1 commit into from
Dec 13, 2021
Merged

Use module inline assembly to embed bitcode #91654

merged 1 commit into from
Dec 13, 2021

Conversation

nikic
Copy link
Contributor

@nikic nikic commented Dec 8, 2021

In LLVM 14, our current method of setting section flags to avoid
embedding the .llvmbc section into final compilation artifacts
will no longer work, see issue #90326. The upstream recommendation
is to instead embed the entire bitcode using module-level inline
assembly, which is what this change does.

I've kept the existing code for platforms where we do not need to
set section flags, but possibly we should always be using the
inline asm approach (which would have to look a bit different for MachO).

r? @nagisa

@nikic
Use module inline assembly to embed bitcode
509dedc 
In LLVM 14, our current method of setting section flags to avoid
embedding the `.llvmbc` section into final compilation artifacts
will no longer work, see issue rust-lang#90326. The upstream recommendation
is to instead embed the entire bitcode using module-level inline
assembly, which is what this change does.

I've kept the existing code for platforms where we do not need to
set section flags, but possibly we should always be using the
inline asm approach.
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 8, 2021
@nikic
Copy link
Contributor Author

nikic commented Dec 8, 2021

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 8, 2021
@bors
Copy link
Contributor

bors commented Dec 8, 2021

⌛ Trying commit 509dedc with merge b31c835a9b55c5a2bd18906c03f20e05012b491e...

@bors
Copy link
Contributor

bors commented Dec 8, 2021

☀️ Try build successful - checks-actions
Build commit: b31c835a9b55c5a2bd18906c03f20e05012b491e (b31c835a9b55c5a2bd18906c03f20e05012b491e)

@rust-timer
Copy link
Collaborator

Queued b31c835a9b55c5a2bd18906c03f20e05012b491e with parent abba5ed, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (b31c835a9b55c5a2bd18906c03f20e05012b491e): comparison url.

Summary: This change led to large relevant regressions 😿 in compiler performance.

  • Large regression in instruction counts (up to 4.2% on incr-unchanged builds of html5ever)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Dec 8, 2021
nagisa
nagisa reviewed Dec 8, 2021
View reviewed changes
compiler/rustc_codegen_llvm/src/back/write.rs
if byte == b'\\' || byte == b'"' {
asm.push(b'\\');
asm.push(byte);
} else if byte < 0x20 || byte >= 0x80 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, I'm somewhat more comfortable with a .byte directive over .ascii with escapes here. Is there any particular reason why we'd be stuck with .ascii?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.byte should work as well. I picked .ascii here for more compact encoding. Though I guess .byte isn't so bad when using decimal rather than hex and saving on the 0x prefix for each byte.

@nagisa
Copy link
Member

nagisa commented Dec 8, 2021

To the best of my knowledge the perf run results are quite irrelevant here, aren't they? Since we only ever embed bitcode by default on iOS targets.

@nagisa
Copy link
Member

nagisa commented Dec 8, 2021

@bors r+

@bors
Copy link
Contributor

bors commented Dec 8, 2021

📌 Commit 509dedc 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 Dec 8, 2021
@nikic
Copy link
Contributor Author

nikic commented Dec 8, 2021

To the best of my knowledge the perf run results are quite irrelevant here, aren't they? Since we only ever embed bitcode by default on iOS targets.

We also embed bitcode in some LTO scenarios (in particular for libstd, which must be usable with and without LTO), though I'm not sure which flag exactly controls that. I suspect the html5-ever incremental regression may be another instance of rust-lang/rustc-perf#1105 though, as it doesn't seem to be using any (cross-crate) LTO.

@cuviper
Copy link
Member

cuviper commented Dec 8, 2021

We also embed bitcode in some LTO scenarios (in particular for libstd, which must be usable with and without LTO), though I'm not sure which flag exactly controls that.

See here:

rust/src/bootstrap/compile.rs

Lines 332 to 342 in 11fb21f

// By default, rustc uses `-Cembed-bitcode=yes`, and Cargo overrides that
// with `-Cembed-bitcode=no` for non-LTO builds. However, libstd must be
// built with bitcode so that the produced rlibs can be used for both LTO
// builds (which use bitcode) and non-LTO builds (which use object code).
// So we override the override here!
//
// But we don't bother for the stage 0 compiler because it's never used
// with LTO.
if stage >= 1 {
cargo.rustflag("-Cembed-bitcode=yes");
}

@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 9, 2021
@bors
Copy link
Contributor

bors commented Dec 13, 2021

⌛ Testing commit 509dedc with merge a737592...

@bors
Copy link
Contributor

bors commented Dec 13, 2021

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing a737592 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 13, 2021
@bors bors merged commit a737592 into rust-lang:master Dec 13, 2021
@rustbot rustbot added this to the 1.59.0 milestone Dec 13, 2021
@nikic nikic mentioned this pull request Dec 13, 2021
Closed
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a737592): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@rustbot rustbot removed the perf-regression Performance regression. label Dec 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nagisa nagisa nagisa left review comments

Assignees

@nagisa nagisa

Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.59.0
Development

Successfully merging this pull request may close these issues.
8 participants
@nikic @rust-timer @bors @nagisa @cuviper @apiraino @rust-highfive @rustbot