adopts simple strategy devised with assistance from mw: Instead of accumulating
(and acting upon) LTO import information over an unbounded number of prior
compilations, just see if the current import set matches the previous import set.
if they don't match, then you cannot reuse the PostLTO build product for that
module.
In either case (of a match or a non-match), we can (and must) unconditionally
emit the current import set as the recorded information in the incremental
compilation cache, ready to be loaded during the next compiler run for use in
the same check described above.
resolves issue 59535.
This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.
Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).
The end results of this change are:
* Rustbuild's build process for the compiler as all the "oh don't forget
the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
parallelism in the main rustc build step rather than splitting
`librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
multiple codegen backends is still supported, and dynamic loading of a
codegen backend is still supported.
Migrate to LLVM{Get,Set}ValueName2
The deprecated `LLVM{Get,Set}ValueName` only work with NUL-terminated
strings, but the `2` variants use explicit lengths, which fits better
with Rust strings and slices. We now use these in new helper functions
`llvm::{get,set}_value_name` that convert to/from `&[u8]`.
Closes#64223.
r? @rkruppe
Use Module::print() instead of a PrintModulePass
llvm::Module has a print() method. It is unnecessary to create a pass just for the purpose of printing LLVM IR.
The deprecated `LLVM{Get,Set}ValueName` only work with NUL-terminated
strings, but the `2` variants use explicit lengths, which fits better
with Rust strings and slices. We now use these in new helper functions
`llvm::{get,set}_value_name` that convert to/from `&[u8]`.
Change Linker for x86_64-fortanix-unknown-sgx target to rust-lld
Changed linker for `x86_64-fortanix-unknown-sgx` target to `rust-lld`
This change needed the RelaxELFRelocations flag to be set for it to work correctly
r? @jethrogb
For SGX, the relocation using the relocation table is done by
the code in rust/src/libstd/sys/sgx/abi/reloc.rs and this code
should not require relocation. Setting RelaxELFRelocations flag
if allows this to happen, hence adding a Target Option for it.
This addresses #65024, as it allows RISC-V target specification
files to set "llvm-abiname": "lp64d". In general, it is useful
for the programmer to be able to set this codegen parameter,
which other languages usually expose under a compiler argument
like "-mabi=<XYZ>".
Fix#64153
This PR changes how the compiler detects if an object file from an upstream crate is a Rust object file or not. Instead of checking if the name starts with the crate name and ends with `.o` (which is not always the case, as described in #64153), it now just checks if the filename ends with `.rcgu.o`.
This fixes#64153. However, ideally we'd clean up the code around filename generation some more. Then this check could be made more robust.
r? @alexcrichton
When performing a "fat" LTO the compiler has a whole mess of codegen
units that it links together. To do this it needs to select one module
as a "base" module and then link everything else into this module.
Previously LTO passes assume that there's at least one module in-memory
to link into, but nowadays that's not always true! With incremental
compilation modules may actually largely be cached and it may be
possible that there's no in-memory modules to work with.
This commit updates the logic of the LTO backend to handle modules a bit
more uniformly during a fat LTO. This commit immediately splits them
into two lists, one serialized and one in-memory. The in-memory list is
then searched for the largest module and failing that we simply
deserialize the first serialized module and link into that. This
refactoring avoids juggling three lists, two of which are serialized
modules and one of which is half serialized and half in-memory.
Closes#63349
Exception for specific cases like linting, additional passes should
be going into the module pass manager (even if they are function
passes). The separate function pass manager is only used for very
early optimization passes.
Rather than apparending passes to the MPM, use the OptimizerLast
and EnabledOnOptLevel0 pass manager builder extension hooks, which
allow adding passes directly before finalization (alias
canonicalization and name-anon-globals).
The main effect and purpose of this change is to add sanitizer
passes at the end of the pipeline, which is where they belong.
In LLVM 9 the address sanitizer can't be used as a pass in the
early function pass manager, because it has a dependence on a
module-level analysis pass.
Check if the archive has already been added to avoid duplicates
This avoids adding archives multiple times, which results in duplicate
objects in the resulting rlib, leading to symbol collision and link
failures. This could happen when crate contains multiple link attributes
that all reference the same archive.
This avoids adding archives multiple times, which results in duplicate
objects in the resulting rlib, leading to symbol collision and link
failures. This could happen when crate contains multiple link attributes
that all reference the same archive.
