Use object crate for .rustc metadata generation #91604
Conversation
|
Some changes occured to rustc_codegen_gcc cc @antoyo |
rust-highfive
added
the
S-waiting-on-review
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit 3e1e7830dac9cc37d464a83b358e8bfeef6bf9b1 with merge 4b464f70d4bb56629e0b06964fcba1d010c0abfd... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts, while .rustc should be part of shared objects, but not loaded into memory. The primary motivation for this change is rust-lang#90326: In LLVM 14, the current way of setting section flags (and in particular, preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this, but switching to the object crate seems like the most elegant, as we already use it for .rmeta, and as it makes this independent of the codegen backend. In particular, we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well, though I have omitted that here, as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well, and adjust the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it, and directly produce the compiled module instead. This does not fix rust-lang#90326 by itself yet, as .llvmbc will need to be handled separately.
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
|
⌛ Trying commit 9488cac with merge 5209ab525db4ef738b98e65d6d5f45ee441de18f... |
|
☀️ Try build successful - checks-actions |
|
Queued 5209ab525db4ef738b98e65d6d5f45ee441de18f with parent 2af5c65, future comparison URL. |
|
Finished benchmarking commit (5209ab525db4ef738b98e65d6d5f45ee441de18f): comparison url. Summary: This change led to large relevant regressions 😿 in compiler performance.
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 @bors rollup=never |
rustbot
added
perf-regression
|
I don't get this regression on deep-vector. Compressed metadata is only relevant for dylibs, while this is an executable. The time diff is reported in monomorphization_collector_graph_walk, which doesn't really look related. I'm confused. |
|
It's almost certainly due to rust-lang/rustc-perf#1105, I wouldn't worry about the incr-unchanged regression for deep-vector. |
|
@bors r+ |
|
📌 Commit 9488cac has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (f9e77f2): 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 |
| BinaryFormat::Elf | ||
| }; | ||
|
|
||
| let mut file = write::Object::new(binary_format, architecture, endianness); |
There was a problem hiding this comment.
This should probably get a file.add_file_symbol(...) call. In cg_clif I used the cgu name as argument.
The new api was introduced in rust-lang/rust#91604
|
Updated cg_clif in bjorn3/rustc_codegen_cranelift@4796207. |
Use object crate for .rustc metadata generation We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts, while .rustc should be part of shared objects, but not loaded into memory. The primary motivation for this change is rust-lang#90326: In LLVM 14, the current way of setting section flags (and in particular, preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this, but switching to the object crate seems like the most elegant, as we already use it for .rmeta, and as it makes this independent of the codegen backend. In particular, we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well, though I have omitted that here, as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well, and adjusts the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it, and directly produce the compiled module instead. This does not `fix` rust-lang#90326 by itself yet, as .llvmbc will need to be handled separately. r? `@nagisa`
We already use the object crate for generating uncompressed .rmeta
metadata object files. This switches the generation of compressed
.rustc object files to use the object crate as well. These have
slightly different requirements in that .rmeta should be completely
excluded from any final compilation artifacts, while .rustc should
be part of shared objects, but not loaded into memory.
The primary motivation for this change is #90326: In LLVM 14, the
current way of setting section flags (and in particular, preventing
the setting of SHF_ALLOC) will no longer work. There are other ways
we could work around this, but switching to the object crate seems
like the most elegant, as we already use it for .rmeta, and as it
makes this independent of the codegen backend. In particular, we
don't need separate handling in codegen_llvm and codegen_gcc.
codegen_cranelift should be able to reuse the implementation as
well, though I have omitted that here, as it is not based on
codegen_ssa.
This change mostly extracts the existing code for .rmeta handling
to allow using it for .rustc as well, and adjusts the codegen
infrastructure to handle the metadata object file separately: We
no longer create a backend-specific module for it, and directly
produce the compiled module instead.
This does not
fix#90326 by itself yet, as .llvmbc will need to behandled separately.
r? @nagisa