Add Armv8-M Mainline targets
This commit enables the Armv8-M Mainline architecture profile.
It adds two targets:
- `thumbv8m.main-none-eabi`
- `thumbv8m.main-none-eabihf`
The second one uses the Floating Point Unit for floating point
operations. It mainly targets the Cortex-M33 processor, which
can have the optional Floating Point Unit extension.
It follows #55041 which does it for Baseline. I will rebase this branch on top of it when it is merged to not create conflicts as we have some files in common. To make it work, it still relies on the Cargo change to be merged (accepting "." in target names, rust-lang/cargo#6255).
The goal would also be to add this target in the CI so that the `core` library is available for everybody. To do this, some changes will be needed to compile successfully the needed libraries:
* `cc-rs` needs to be updated to allow compiling C code for Armv8-M architectures profiles. It is only a few lines to add [here](a76611ad98/src/lib.rs (L1299)).
* Some assembly files in `builtins` in `compiler-rt` were not assembling for Armv8-M Mainline. I sent changes [upstream](https://reviews.llvm.org/D51854) to that project to fix that. The Rust version of `compiler-rt` will have to be updated to contain [that commit](a34cdf8bb4).
I tested it using the [Musca-A Test Chip board](https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board) but more intensively on the [Armv8-M FVP](https://developer.arm.com/products/system-design/fixed-virtual-platforms) (emulation platform). I am going to try to release my test code soon, once I tidy it up 👍
This commit enables the Armv8-M Mainline architecture profile.
It adds two targets:
- thumbv8m.main-none-eabi
- thumbv8m.main-none-eabihf
The second one uses the Floating Point Unit for floating point
operations. It mainly targets the Cortex-M33 processor, which
can have the optional Floating Point Unit extension.
Pass additional linker flags when targeting Fuchsia
This is a follow up to 8aa9267 which changed the driver to use lld
directly rather than invoking it through Clang. This change ensures
we pass all the necessary flags to lld.
rustc_target: separate out an individual alignment quantity type from Align.
Before this PR, `rustc_target::abi::Align` combined "power-of-two alignment quantity" semantics, with a distinction between ABI (required) and preferred alignment (by having two quantities).
After this PR, `Align` is only *one* such quantity, and a new `AbiAndPrefAlign` type is introduced to hold the pair of ABI and preferred `Align` quantities.
`Align` is used everywhere one quantity is necessary/sufficient, simplifying some of the code in codegen/miri, while `AbiAndPrefAlign` only in layout computation (to propagate preferred alignment).
r? @oli-obk cc @nagisa @RalfJung @nikomatsakis
Add SGX target to rustc
This adds the `x86_64-fortanix-unknown-sgx` target specification to the Rust compiler. See #56066 for more details about this target.
This is a follow up to 8aa9267 which changed the driver to use lld
directly rather than invoking it through Clang. This change ensures
we pass all the necessary flags to lld.
The requirements here are not "ELFv1" requirements, but big-endian
requirements, as the extension or non-extension of the argument is
necessary to put the argument in the correct half of the register.
Parameter passing in the ELFv2 ABI needs these same transformations.
Since this code makes no difference on little-endian machines, simplify
it to use the same code path everywhere.
This commit cleans up allocator injection logic found in the compiler
around selecting the global allocator. It turns out that now that
jemalloc is gone the compiler never actually injects anything! This
means that basically everything around loading crates here and there can
be easily pruned.
This also removes the `exe_allocation_crate` option from custom target
specs as it's no longer used by the compiler anywhere.
Support for the program data address space option of LLVM's Target Datalayout
This was introduced recently (specifically, for AVR, cc @dylanmckay).
(I came up with this when attempting to run [avr-rust](https://github.com/avr-rust/rust) rebased on the latest [rust-lang](https://github.com/rust-lang/rust) commits. If this requires a different design, some additional discussions, or is not something to pursue right now, I'd be happy to close this PR).
Note that this somewhat overlaps with @DiamondLovesYou's #51576, I think, although the implementation here is significantly simpler: Since the address space applies to _all_ program data, we can just check the pointee's type whenever we create an LLVM pointer type. If it is a function we use the program data address space; if not we use the default address space.
cc @eddyb, who has been reviewing #51576
Ref: https://llvm.org/docs/LangRef.html#data-layout
rustc: Delete grouping logic from the musl target
This commit deletes the injection of `-(` and `-)` options to the linker
for the musl targets. This actually causes problems today on nightly if
you execute:
$ echo 'fn main() {}' >> foo.rs
$ rustc --target x86_64-unknown-linux-musl -C panic=abort
you get a linker error about "cannot nest groups". This comes about
because rustc injects its own `--start-group` and `--end-group`
variables which clash with the outer `-(` and `-)` variables. It's not
entirely clear to me why this doesn't affect the musl target by default
(in `-C panic=unwind` mode).
The compiler's own injection of `--start-group` and `--end-group` should
solve the issues mentioned in the comment for injecting `-(` and `-)` as
well.
Use lld directly for Fuchsia target
Fuchsia already uses lld as the default linker, so there's no reason
to always invoke it through Clang, instead we can simply invoke lld
directly and pass the set of flags that matches Clang.
Fuchsia already uses lld as the default linker, so there's no reason
to always invoke it through Clang, instead we can simply invoke lld
directly and pass the set of flags that matches Clang.
This commit deletes the injection of `-(` and `-)` options to the linker
for the musl targets. This actually causes problems today on nightly if
you execute:
$ echo 'fn main() {}' >> foo.rs
$ rustc --target x86_64-unknown-linux-musl -C panic=abort
you get a linker error about "cannot nest groups". This comes about
because rustc injects its own `--start-group` and `--end-group`
variables which clash with the outer `-(` and `-)` variables. It's not
entirely clear to me why this doesn't affect the musl target by default
(in `-C panic=unwind` mode).
The compiler's own injection of `--start-group` and `--end-group` should
solve the issues mentioned in the comment for injecting `-(` and `-)` as
well.
This commit adds opt-in support to the compiler to link to `jemalloc` in
the compiler. When activated the compiler will depend on `jemalloc-sys`,
instruct jemalloc to unprefix its symbols, and then link to it. The
feature is activated by default on Linux/OSX compilers for x86_64/i686
platforms, and it's not enabled anywhere else for now. We may be able to
opt-in other platforms in the future! Also note that the opt-in only
happens on CI, it's otherwise unconditionally turned off by default.
Closes#36963
This commit removes all jemalloc related submodules, configuration, etc,
from the bootstrap, from the standard library, and from the compiler.
This will be followed up with a change to use jemalloc specifically as
part of rustc on blessed platforms.
PR #51953 enabled the Atomic*.{load,store} API on MSP430. Unfortunately, the
LLVM backend doesn't currently support those atomic operations, so this commit
removes the API and leaves instructions on how and when to enable it in the
future.
The upcoming SIMD support in the wasm target is unique from the other
platforms where it's either unconditionally available or not available,
there's no halfway where a subsection of the program can use it but no
other parts of the program can use it. In this world it's valid for wasm
SIMD args to always be passed by value and there's no need to pass them
by reference.
This commit adds a new custom target specification option
`simd_types_indirect` which defaults to `true`, but the wasm backend
disables this and sets it to `false`.
Disable the PLT where possible to improve performance
for indirect calls into shared libraries.
This optimization is enabled by default where possible.
- Add the `NonLazyBind` attribute to `rustllvm`:
This attribute informs LLVM to skip PLT calls in codegen.
- Disable PLT unconditionally:
Apply the `NonLazyBind` attribute on every function.
- Only enable no-plt when full relro is enabled:
Ensures we only enable it when we have linker support.
- Add `-Z plt` as a compiler option
Revert most of MaybeUninit, except for the new API itself
This reverts most of https://github.com/rust-lang/rust/pull/53508/ for perf reasons (first commit reverts that entire PR), except for the new API itself (added back in 2nd commit).
