-
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
Refactor object file handling #70384
Refactor object file handling #70384
Conversation
It's unused by any existing targets, and soon we'll be embedding full bitcode by default anyway.
7d2aa8c
to
72f1c6c
Compare
In theory this shouldn't affect performance at all, but let's check that: @bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit 72f1c6cfed177a356c7e05d16ba778cb1cb45078 with merge 8753044243364ce6751612dea9eae4439dcad8ce... |
If I remember correctly "marker" bitcode embedding had something to do with iOS compatibility? #35968 has some discussion on it; but @alexcrichton would know more about that anyway. |
☀️ Try build successful - checks-azure |
Queued 8753044243364ce6751612dea9eae4439dcad8ce with parent cdb50c6, future comparison URL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm always a fan of cleanups :)
The perf impact is negligible, as expected. |
Currently, there are three fields in `ModuleConfig` that dictate how object files are emitted: `emit_obj`, `obj_is_bitcode`, and `embed_bitcode`. Some of the combinations of these fields are nonsensical, in particular having both `obj_is_bitcode` and `embed_bitcode` true at the same time. Also, currently: - we needlessly emit and then delete a bytecode file if `obj_is_bitcode` is true but `emit_obj` is false; - we needlessly embed bitcode in the LLVM module if `embed_bitcode` is true and `emit_obj` is false. This commit combines the three fields into one, with a new type `EmitObj` (and the auxiliary `BitcodeSection`) which can encode five different possibilities. In the old code, `set_flags` would set `obj_is_bitcode` and `embed_bitcode` on all three of the configs (`modules`, `allocator`, `metadata`) if the relevant other conditions were met, even if no object code needed to be emitted for one or more of them. Whereas `start_async_codegen` would set `emit_obj`, but only for those configs that need it. In the new code, `start_async_codegen` does all the work of setting `emit_obj`, and it only does that for the configs that need it. `set_flags` no longer sets anything related to object file emission.
It makes things a little clearer.
72f1c6c
to
a50cca9
Compare
@alexcrichton New code is up. I reinstated marker bitcode sections (in a nicer fashion than we had before) and did other minor changes you suggested where possible. |
@bors: r+ |
📌 Commit a50cca9 has been approved by |
…ndling, r=alexcrichton Refactor object file handling Some preliminary clean-ups that grease the path to rust-lang#66961. r? @alexcrichton
Rollup of 6 pull requests Successful merges: - rust-lang#70384 (Refactor object file handling) - rust-lang#70397 (add 'fn write_u16s' to Memory) - rust-lang#70413 (Fix incorrect pattern warning "unreachable pattern") - rust-lang#70428 (`error_bad_item_kind`: add help text) - rust-lang#70429 (Clean up E0459 explanation) - rust-lang#70437 (Miri float->int casts: be explicit that this is saturating) Failed merges: r? @ghost
Some preliminary clean-ups that grease the path to #66961.
r? @alexcrichton