rustllvm relies on the `LLVMRustStringWriteImpl` symbol existing, but
this symbol was previously defined in a *downstream* crate
(rustc_codegen_llvm, which depends on rustc_llvm.
While this somehow worked under the old 'separate bootstrap step for
codegen' scheme, it meant that rustc_llvm could not actually be built by
itself, since it relied linking to the downstream rustc_codegen_llvm
crate.
Now that librustc_codegen_llvm is just a normal crate, we actually try
to build a standalone rustc_llvm when we run tests. This commit moves
`LLVMRustStringWriteImpl` into rustc_llvm (technically the rustllvm
directory, which has its contents built by rustc_llvm). This ensures
that we can build each crate in the graph by itself, without requiring
that any downstream crates be linked in as well.
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.
Add `{f32,f64}::approx_unchecked_to<Int>` unsafe methods
As discussed in https://github.com/rust-lang/rust/issues/10184
Currently, casting a floating point number to an integer with `as` is Undefined Behavior if the value is out of range. `-Z saturating-float-casts` fixes this soundness hole by making `as` “saturate” to the maximum or minimum value of the integer type (or zero for `NaN`), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an `unsafe fn` alternative for users who know through some other mean that their values are in range.
<del>The “fit” wording is copied from https://llvm.org/docs/LangRef.html#fptoui-to-instruction, but I’m not certain what it means exactly. Presumably this is after rounding towards zero, and the doc-test with `i8::MIN` seems to confirm this.</del> Clang presumably uses those LLVM intrinsics to implement C and C++ casts, whose respective standard specify that the value *after truncating to keep its integral part* must be representable in the target type.
Rename `bool::then_*` to `bool::to_option_*` and use where appropriate
Name change following https://github.com/rust-lang/rfcs/pull/2757. Also try it out throughout the compiler in places I think makes the code more readable.
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
As discussed in https://github.com/rust-lang/rust/issues/10184
Currently, casting a floating point number to an integer with `as` is Undefined Behavior if the value is out of range. `-Z saturating-float-casts` fixes this soundness hole by making `as` “saturate” to the maximum or minimum value of the integer type (or zero for `NaN`), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an `unsafe fn` alternative for users who know through some other mean that their values are in range.
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]`.
rustc: split FnAbi's into definitions/direct calls ("of_instance") and indirect calls ("of_fn_ptr").
After this PR:
* `InstanceDef::Virtual` is only used for "direct" virtual calls, and shims around those calls use `InstanceDef::ReifyShim` (i.e. for `<dyn Trait as Trait>::f as fn(_)`)
* this could easily be done for intrinsics as well, to allow their reification, but I didn't do it
* `FnAbi::of_instance` is **always** used for declaring/defining an `fn`, and for direct calls to an `fn`
* this is great for e.g. https://github.com/rust-lang/rust/pull/65881 (`#[track_caller]`), which can introduce the "caller location" argument into "codegen signatures" by only changing `FnAbi::of_instance`, after this PR
* `FnAbi::of_fn_ptr` is used primarily for indirect calls, i.e. to `fn` pointers
* *not* virtual calls (which use `FnAbi::of_instance` with `InstanceDef::Virtual`)
* there's also a couple uses where the `rustc_codegen_llvm` needs to declare (i.e. FFI-import) an LLVM function that has no Rust declaration available at all
* at least one of them could probably be a "weak lang item" instead
As there are many steps, this PR is best reviewed commit by commit - some of which arguably should be in their own PRs, I may have gotten carried away a bit.
cc @nagisa @rkruppe @oli-obk @anp
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.
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.
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.
Feature gating *declarations* => new crate `rustc_feature`
This PR moves the data-oriented parts of feature gating into its own crate, `rustc_feature`.
The parts consist of some data types as well as `accepted`, `active`, `removed`, and `builtin_attrs`.
Feature gate checking itself remains in `syntax::feature_gate::check`. The parts which define how to emit feature gate errors could probably be moved to `rustc_errors` or to the new `rustc_session` crate introduced in #66878. The visitor itself could probably be moved as a pass in `rustc_passes` depending on how the dependency edges work out.
The PR also contains some drive-by cleanup of feature gate checking. As such, the PR probably best read commit-by-commit.
r? @oli-obk
cc @petrochenkov
cc @Mark-Simulacrum
Allow global references via ForeignItem and Item for the same symbol name during LLVM codegen
Combining CGUs can result in code that references a static variable through both
an Item and a ForeignItem with the same name. We don't care that the global was
already created by a ForeignItem reference when we see the Item reference, as
long as the LLVM types of the ForeignItem and Item match.
Fixes#66464
Store pointer width as u32 on Config
This removes the dependency on IntTy, UintTy from Session.
It's not obviously a win, but it seems a bit odd to store the AST IntTy/UintTy in Session, rather we store the pointer width as an integer and add normalization methods to IntTy and UintTy.
Aaron Hill