| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Don't copy bytecode files into the incr. comp. cache.
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires, so I'm re-sending this patch!
|
|
|
|
This commit finishes work first pioneered in #70458 and started in #71528.
The `-C bitcode-in-rlib` option, which has not yet reached stable, is
renamed to `-C embed-bitcode` since that more accurately reflects what
it does now anyway. Various tests and such are updated along the way as
well.
This'll also need to be backported to the beta channel to ensure we
don't accidentally stabilize `-Cbitcode-in-rlib` as well.
|
|
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
|
|
Remove -Z no-landing-pads flag
Since #67502, `-Z no-landing-pads` will cause all attempted unwinds to abort since we don't generate a `try` / `catch`. This previously worked because `__rust_try` was located in libpanic_unwind which is always compiled with `-C panic=unwind`, but `__rust_try` is now directly inline into the crate that uses `catch_unwind`.
As such, `-Z no-landing-pads` is now mostly useless and people should use `-C panic=abort` instead.
|
|
Store LLVM bitcode in object files, not compressed
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
|
|
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
|
|
|
|
|
|
Ignore -Zprofile when building compiler_builtins
#70846 made the `compiler_builtins` crate ignore the default codegen-units setting and instead always split each function into a different codegen unit.
This unfortunately breaks `-Zprofile` which requires a single codegen unit per crate (see #71283). You can notice this when building with `cargo -Zbuild-std` and `RUSTFLAGS` containing `-Zprofile`.
This PR works around this issue by just ignoring `-Zprofile` for the `compiler-builtins` crate.
|
|
It defaults to true, but Cargo will set this to false whenever it can to
reduce compile times.
|
|
|
|
This lets us specify the default at the options declaration point,
instead of using `.unwrap(default)` or `None | Some(default)` at some
use point far away. It also makes the code more concise.
|
|
r=Mark-Simulacrum
Clean up `ModuleConfig` initialization
Because it's currently a mess.
r? @Mark-Simulacrum
|
|
|
|
That way it matches `ModuleKind::Regular`.
|
|
There are three `ModuleConfigs`, one for each `ModuleKind`. The code to
initialized them is spaghetti imperative code that sets each field to a
default value and then modifies many fields in complicated ways. This
makes it very hard to tell what value ends up in each field in each
config.
For example, the `modules_config.emit_pre_lto_bc` field is set twice,
which means it can be set to true and then incorrectly set back to
false. (This probably hasn't been noticed because it happens in a very
obscure case.)
This commit changes the code to a declarative style in which
`ModuleConfig::new` initializes all fields and then they are never
changed again. This is slightly more concise and much easier to read.
(And it fixes the abovementioned `emit_pre_lto_bc` error as well.)
|
|
The condition checks if `sess.opts.output_types` doesn't contain
`OutputType::Assembly` within a match arm that is only reached if
`sess.opts.output_types` contains `OutputType::Assembly`.
|
|
|
|
|
|
Specifically, remove both `-Z no_integrated_as` and
`TargetOptions::no_integrated_as`. The latter was only used for the
`msp430_none_elf` platform, for which it's no longer required.
|
|
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's unused by any existing targets, and soon we'll be embedding full
bitcode by default anyway.
|
|
Refactor `codegen`
`codegen` in `src/librustc_codegen_llvm/back/write.rs` is long and has complex control flow. These commits refactor it and make it easier to understand.
|
|
Because the `(true, true)` combination isn't valid.
|
|
(clippy::let_and_return)
|
|
|
|
|
|
|
|
|
|
anything.
For example: `if let Some(_) = foo() {}` can be reduced to `if foo().is_some() {}` (clippy::redundant_pattern_matching)
|
|
|
|
|
|
|
|
The new pass manager can be enabled using
-Z new-llvm-pass-manager=on.
|
|
|
|
used outside of the LLVM backend.
|
|
|
|
pnkfelix:fix-66530-by-propagating-fatal-error-from-worker, r=matthewjasper
When a codegen worker has a FatalError, propagate it instead of ICE'ing.
Fix #66530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
