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.
Clean up handling of `-Z pgo-gen` commandline option.
This PR adapts the `-Z pgo-gen` flag to how Clang and GCC handle the corresponding `-fprofile-generate` flag. In particular, the flag now optionally takes a directory to place the profiling data in and allows to omit the argument (instead of having to pass an empty string).
Exclude profiler-generated symbols from MSVC __imp_-symbol workaround.
LLVM's profiling instrumentation adds a few symbols that are used by the profiler runtime. Since these show up as globals in the LLVM IR, the compiler generates `dllimport`-related `__imp_` stubs for them. This can lead to linker errors because the instrumentation symbols have weak linkage or are in a comdat section, but the `__imp_` stubs aren't.
Instead of trying to replicate the linkage/comdat setup for the stubs, this PR just excludes the profiler-related symbols from stub-generation since they aren't supposed to be referenced via `__declspec(dllimport)` anywhere anyway.
r? @alexcrichton
EDIT: I considered making this more general, i.e. inferring from the symbol name if it is a Rust symbol or not. But then I figured out that that would yield false negatives for `#[no_mangle]` et al, so I went with a blacklist approach.
Show better errors for LLVM IR output
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.
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.
This commit updates the LLVM branch to the rebased version of the
upstream release/8.x branch. This includes a wasm patch which means that
the `rewrite_imports` pass in rustc is no longer needed (yay!) and we
can instead rely on `wasm-import-module`, an attribute we're already
emitting, to take care of all the work.
rustc: Implement incremental "fat" LTO
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
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
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
Instead of maybe storing its own sysroot and maybe deferring to the one
in `Session::opts`, just clone the latter when necessary so one is
always directly available. This removes the need for the getter.
