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.
If the Rust LLVM fork is used, enable the -mergefunc-use-aliases
flag, which will create aliases for merged functions, rather than
inserting a call from one to the other.
A number of codegen tests needed to be adjusted, because functions
that previously fell below the thunk limit are now being merged.
Merging is prevented either using -C no-prepopulate-passes, or by
making the functions non-identical.
I expect that this is going to break something, somewhere, because
it isn't able to deal with aliases properly, but we won't find out
until we try :)
This fixes#52651.
Update emscripten
This updates emscripten to 1.38.15, which is based on LLVM 6.0.1 and would allow us to drop code for handling LLVM 4.
The main issue I ran into is that exporting statics through `EXPORTED_FUNCTIONS` no longer works. As far as I understand exporting non-functions doesn't really make sense under emscripten anyway, so I've modified the symbol export code to not even try.
Closes#52323.
This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.
This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.
Closes#53322
In some profiling on OSX I saw the `write` syscall as quite high up on
the profiling graph, which is definitely not good! It looks like we're
setting the output stream of an object file as directly to a file
descriptor which means that we run the risk of doing lots of little
writes rather than a few large writes.
This commit fixes this issue by adding a buffered stream on the output,
causing the `write` syscall to disappear from the profiles on OSX.
Fix -Wpessimizing-move warnings in rustllvm/PassWrapper
These are producing warnings when building rustc (`warning: moving a local object in a return statement prevents copy elision [-Wpessimizing-move]`).
rustc: Work around an upstream wasm ThinLTO bug
This commit implements a workaround for an [upstream LLVM bug][1] where custom
sections were accidentally duplicated amongst codegen units when ThinLTO passes
were performed. This is due to the fact that custom sections for wasm are stored
as metadata nodes which are automatically imported into modules when ThinLTO
happens. The fix here is to forcibly delete the metadata node from imported
modules before LLVM has a chance to try to copy it over.
[1]: https://bugs.llvm.org/show_bug.cgi?id=38184
This commit implements a workaround for an [upstream LLVM bug][1] where custom
sections were accidentally duplicated amongst codegen units when ThinLTO passes
were performed. This is due to the fact that custom sections for wasm are stored
as metadata nodes which are automatically imported into modules when ThinLTO
happens. The fix here is to forcibly delete the metadata node from imported
modules before LLVM has a chance to try to copy it over.
[1]: https://bugs.llvm.org/show_bug.cgi?id=38184
This commit removes a hack in our ThinLTO passes which removes available
externally functions manually. The [upstream bug][1] has long since been fixed,
so we should be able to rely on LLVM natively for this now!
[1]: https://bugs.llvm.org/show_bug.cgi?id=35736
This commit upgrades the main LLVM submodule to LLVM's current master branch.
The LLD submodule is updated in tandem as well as compiler-builtins.
Along the way support was also added for LLVM 7's new features. This primarily
includes the support for custom section concatenation natively in LLD so we now
add wasm custom sections in LLVM IR rather than having custom support in rustc
itself for doing so.
Some other miscellaneous changes are:
* We now pass `--gc-sections` to `wasm-ld`
* The optimization level is now passed to `wasm-ld`
* A `--stack-first` option is passed to LLD to have stack overflow always cause
a trap instead of corrupting static data
* The wasm target for LLVM switched to `wasm32-unknown-unknown`.
* The syntax for aligned pointers has changed in LLVM IR and tests are updated
to reflect this.
* The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]
Nowadays we've been mostly only upgrading whenever there's a major release of
LLVM but enough changes have been happening on the wasm target that there's been
growing motivation for quite some time now to upgrade out version of LLD. To
upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet
another version of LLVM on the builders.
The revision of LLVM in use here is arbitrarily chosen. We will likely need to
continue to update it over time if and when we discover bugs. Once LLVM 7 is
fully released we can switch to that channel as well.
[llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382
The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc
pass enabled and it hugely reduces code size (for example it shaves off 10% of the
final Servo executable). This patch reenables it.
The LLVM PassManager has a PrepareForThinLTO flag, which is intended
when compilation occurs in conjunction with linking by ThinLTO. The
flag has two effects:
* The NameAnonGlobal pass is run after all other passes, which
ensures that all globals have a name.
* In optimized builds, a number of late passes (mainly related to
vectorization and unrolling) are disabled, on the rationale that
these a) will increase codesize of the intermediate artifacts
and b) will be run by ThinLTO again anyway.
This patch enables the use of PrepareForThinLTO if Thin or ThinLocal
linking is used.
The background for this change is the CI failure in #49479, which
we assume to be caused by the NameAnonGlobal pass not being run.
As this changes which passes LLVM runs, this might have performance
(or other) impact, so we want to land this separately.
In `LLVMRustHasFeature()`, rather than using `MCInfo->getFeatureTable()`
that is specific to Rust's LLVM fork, we can use this in LLVM 6:
/// Check whether the subtarget features are enabled/disabled as per
/// the provided string, ignoring all other features.
bool checkFeatures(StringRef FS) const;
Now rustc using external LLVM can also have `target_feature`.
LLVM has since removed the `CodeModel::Default` enum value in favor of an
`Optional` implementationg throughout LLVM. Let's mirror the same change in Rust
and update the various bindings we call accordingly.
Removed in llvm-mirror/llvm@9aafb854c
This commit is the next attempt to enable multiple codegen units by default in
release mode, getting some of those sweet, sweet parallelism wins by running
codegen in parallel. Performance should not be lost due to ThinLTO being on by
default as well.
Closes#45320
This commit implements a workaround for #46346 which basically just
avoids triggering the situation that LLVM's bug
https://bugs.llvm.org/show_bug.cgi?id=35562 arises. More details can be
found in the code itself but this commit is also intended to ...
Closes#46346
