Ensure that inliner inserts lifetime markers if they have been emitted during
codegen. Otherwise if allocas from inlined functions are merged together,
lifetime markers from one function might invalidate load & stores performed
by the other one.
rustllvm: Use .init_array rather than .ctors
LLVM TargetMachines default to using the (now-legacy) .ctors
representation of init functions. Mixing .ctors and .init_array
representations can cause issues when linking with lld.
This happens in practice for:
* Our profiling runtime which is currently implicitly built with
.init_array since it is built by clang, which sets this field.
* External C/C++ code that may be linked into the same process.
Fixes: #71233
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.
LLVM TargetMachines default to using the (now-legacy) .ctors
representation of init functions. Mixing .ctors and .init_array
representations can cause issues when linking with lld.
This happens in practice for:
* Our profiling runtime which is currently implicitly built with
.init_array since it is built by clang, which sets this field.
* External C/C++ code that may be linked into the same process.
To support legacy systems which may use .ctors, targets may now specify
that they use .ctors via the use_ctors attribute which defaults to
false.
For debugging and manual control, -Z use-ctors-section=yes/no will allow
manual override.
Fixes: #71233
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.
The default ThinLTO pre-link pipeline does not include optimizer last
extension points. Thus, when using the new LLVM pass manager & ThinLTO
& sanitizers on any opt-level different from zero, the sanitizer
function passes would be omitted from the pipeline.
Add optimizer last extensions points manually to the pipeline, but guard
registration with stage check in the case this behaviour changes in the
future.
Enable use-after-scope checks by default when using AddressSanitizer.
They allow to detect incorrect use of stack objects after their scope
have already ended. The detection is based on LLVM lifetime intrinsics.
To facilitate the use of this functionality, the lifetime intrinsics are
now emitted regardless of optimization level if enabled sanitizer makes
use of them.
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.
Update the minimum external LLVM to 7
LLVM 7 is over a year old, which should be plenty for compatibility. The
last LLVM 6 holdout was llvm-emscripten, which went away in #65501.
I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions`,
which was broken by #66522.
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.
LLVM 7 is over a year old, which should be plenty for compatibility. The
last LLVM 6 holdout was llvm-emscripten, which went away in #65501.
I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions`,
which was broken by #66522.
Use LLVMDisposePassManager instead of raw delete in rustllvm
LLVM has a dedicated API call which wraps the destructor invocation for the PassManager.
Rust invokes it [otherwhere](d63b24ffcc/src/librustc_codegen_llvm/back/write.rs (L446-L447)), but not in the `LLVMRustWriteOutputFile`.
Since `LLVMDisposePassManager` might be extended to perform additional cleanup actions in the future, this change replaces raw destructor invocation with that API call.
Configure LLVM module PIC level
As of LLVM 9, this is required for 32-bit PowerPC to properly generate
PLT references. Previously, only BigPIC was supported; now LLVM supports
both BigPIC and SmallPIC, and there is no default value provided.
As of LLVM 9, this is required for 32-bit PowerPC to properly generate
PLT references. Previously, only BigPIC was supported; now LLVM supports
both BigPIC and SmallPIC, and there is no default value provided.
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>".
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.
I was trying to output LLVM IR directly to the console:
$ rustc hello.rs --emit=llvm-ir -o /dev/stdout
LLVM ERROR: IO failure on output stream: Bad file descriptor
Now `LLVMRustPrintModule` returns an error, and we print:
error: failed to write LLVM IR to /dev/stdout.hello.7rcbfp3g-cgu.0.rcgu.ll: Permission denied
... which is more informative.
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
cc #57968
cc rust-lang/cargo#6643
The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
