Add 2048-bit HvxVectorPair support to Hexagon SIMD ABI checks
Previously, rustc rejected HvxVectorPair types in function signatures because the HEXAGON_FEATURES_FOR_CORRECT_FIXED_LENGTH_VECTOR_ABI array only had entries for vectors up to 1024 bits. This caused the ABI checker to emit "unsupported vector type" errors for 2048-bit HvxVectorPair (used in 128-byte HVX mode).
Add 2048 byte entry to allow HvxVectorPair to be passed in extern "C" funcs when the hvx-length128b is enabled.
Previously, rustc rejected HvxVectorPair types in function signatures
because the HEXAGON_FEATURES_FOR_CORRECT_FIXED_LENGTH_VECTOR_ABI array
only had entries for vectors up to 1024 bits. This caused the ABI checker
to emit "unsupported vector type" errors for 2048-bit HvxVectorPair
(used in 128-byte HVX mode).
Add 2048 byte entry to allow HvxVectorPair to be passed
in extern "C" funcs when the hvx-length128b is enabled.
Add `s390x-unknown-none-softfloat` with `RustcAbi::Softfloat`
followup on rust-lang/rust#150766
add an `s390x-unknown-none-softfloat` target to use for kernel compilation, as the Linux kernel does not wish to pay the overhead of saving float registers by default on kernel switch. this target's `extern "C"` ABI is unspecified, so it is unstable and subject to change between versions, just like the Linux intrakernel ABI and `extern "Rust"` ABIs are unstable.
enforce target feature incompatibility by adding `RustcAbi::Softfloat`. this is itself just a rename of `RustcAbi::X86Softfloat`, accepting both "x86-softfloat" and "softfloat" as valid strings in the target.json format. the target-features of `"soft-float"` and `"vector"` are incompatible for s390x, so issue a compatibility warning if they are combined.
Set crt_static_allow_dylibs to true for Emscripten target
And add a test. This is followup work to rust-lang/rust#151704. It introduced a regression where cargo is now unwilling to build cdylibs for Emscripten because `crt_static_default` is `true` but `crt_static_allows_dylibs` is `false`. Unfortunately the added test does not fail without the change because the validation logic is in Cargo, not in rustc. But it's good to have some coverage of this anyways.
This target is intended to be used for kernel development. Becasue on s390x
float and vector registers overlap we have to disable the vector extension.
The default s390x-unknown-gnu-linux target will not allow use of
softfloat.
Co-authored-by: Jubilee <workingjubilee@gmail.com>
And add a test. This is followup work to PR 151704. It introduced a regression where
cargo is now unwilling to build cdylibs for Emscripten because `crt_static_default` is
`true` but `crt_static_allows_dylibs` is `false`. Unfortunately the added test does not
fail without the change because the validation logic is in Cargo, not in rustc. But it's
good to have some coverage of this anyways.
Update hexagon target linker configurations
* hexagon-unknown-qurt: Use hexagon-clang from Hexagon SDK instead of rust-lld
* hexagon-unknown-linux-musl: Use hexagon-unknown-linux-musl-clang from the open source toolchain instead of rust-lld.
* hexagon-unknown-none-elf: Keep rust-lld but fix the linker flavor.
rust-lld is appropriate for a baremetal target but for traditional programs that depend on libc, using clang's driver makes the most sense.
This makes cdylibs compile to working Emscripten dynamic libraries without passing extra
RUSTFLAGS. This was previously approved as PR 98358 but there were CI failures that I
never got around to fixing.
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
x86 soft-float feature: mark it as forbidden rather than unstable
I am not sure why I made it "unstable" in f755f4cd1a; I think at the time "forbidden" did not work for some reason.
Making it "forbidden" instead has no significant effect on `-Ctarget-feature` use, it just changes the warning. It *does* have the effect that one cannot query this using `cfg(target_feature)` on nightly any more, but that seems fine to me. It only ever worked as an accidental side-effect of f755f4cd1a anyway.
r? @workingjubilee
abi: add a rust-preserve-none calling convention
This is the conceptual opposite of the rust-cold calling convention and is particularly useful in combination with the new `explicit_tail_calls` feature.
For relatively tight loops implemented with tail calling (`become`) each of the function with the regular calling convention is still responsible for restoring the initial value of the preserved registers. So it is not unusual to end up with a situation where each step in the tail call loop is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived and more like a conceptual inverse of `rust-cold`, but could not come with a great name (`rust-cold` is itself not a great name: cold in what context? from which perspective? is it supposed to mean that the function is rarely called?)
Add new Tier 3 targets for ARMv6
Adds three new targets to support ARMv6 processors running bare-metal:
* `armv6-none-eabi` - Arm ISA, soft-float
* `armv6-none-eabihf` - Arm ISA, hard-float
* `thumbv6-none-eabi` - Thumb-1 ISA, soft-float
There is no `thumbv6-none-eabihf` target because as far as I can tell, hard-float isn't support with the Thumb-1 instruction set (and you need the ARMv6T2 extension to enable Thumb-2 support).
The targets require ARMv6K as a minimum, which allows the two Arm ISA targets to have full CAS atomics. LLVM has a bug which means it emits some ARMv6K instructions even if you only call for ARMv6, and as no-one else has noticed the bug, and because basically all ARMv6 processors have ARMv6K, I think this is fine. The Thumb target also doesn't have any kind of atomics, just like the Armv5TE and Armv4 targets, because LLVM was emitting library calls to emulate them.
Testing will be added to https://github.com/rust-embedded/aarch32 once the target is accepted. I already have tests for the other non-M arm-none-eabi targets, and those tests pass on these targets.
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I have listed myself. If accepted, I'll talk to the Embedded Devices Working Group about adding this one to the rosta with all the others they support.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
You might prefer `arm-none-eabi`, because `arm-unknown-linux-gnu` is an ARMv6 target - the implicit rule seems to be that if the Arm architecture version isn't specified, it's assumed to be v6. However, `armv6-none-eabi` seemed to fit better between `armv5te-none-eabi` and `armv7a/armv7r-none-eabi`.
The hamming distance between `thumbv6-none-eabi` and `thumbv6m-none-eabi` is unfortunately low, but I don't know how to make it better. They *are* the ARMv6 and ARMv6-M targets, and its perhaps not worse than `armv7a-none-eabi` and `armv7r-none-eabi`.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
No different to any other arm-none-eabi target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Noted.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate...
Same as other arm-none-eabi targets.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
Same as other arm-none-eabi targets.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Noted.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Noted
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
Noted
Three targets, covering A32 and T32 instructions, and soft-float and
hard-float ABIs. Hard-float not available in Thumb mode. Atomics
in Thumb mode require __sync* functions from compiler-builtins.
This is the conceptual opposite of the rust-cold calling convention and
is particularly useful in combination with the new `explicit_tail_calls`
feature.
For relatively tight loops implemented with tail calling (`become`) each
of the function with the regular calling convention is still responsible
for restoring the initial value of the preserved registers. So it is not
unusual to end up with a situation where each step in the tail call loop
is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers
are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived
and more like a conceptual inverse of `rust-cold`, but could not come
with a great name (`rust-cold` is itself not a great name: cold in what
context? from which perspective? is it supposed to mean that the
function is rarely called?)
Add Tier 3 Thumb-mode targets for Armv7-A, Armv7-R and Armv8-R
We currently have targets for bare-metal Armv7-R, Armv7-A and Armv8-R, but only in Arm mode. This PR adds five new targets enabling bare-metal support on these architectures in Thumb mode.
This has been tested using https://github.com/rust-embedded/aarch32/compare/main...thejpster:aarch32:support-thumb-mode-v7-v8?expand=1 and they all seem to work as expected.
However, I wasn't sure what to do with the maintainer lists as these are five new targets, but they share the docs page with the existing Arm versions. I can ask the Embedded Devices WG Arm Team about taking on these ones too, but whether Arm themselves want to take them on I guess is a bigger question.
* hexagon-unknown-qurt: Use hexagon-clang from Hexagon SDK instead of
rust-lld
* hexagon-unknown-linux-musl: Use hexagon-unknown-linux-musl-clang from
the open source toolchain instead of rust-lld.
* hexagon-unknown-none-elf: Keep rust-lld but fix the linker flavor.
rust-lld is appropriate for a baremetal target but for traditional
programs that depend on libc, using clang's driver makes the most
sense.
Fixes for LLVM 22 compatibility
This includes three fixes for LLVM 22 compatibility:
* Update the AMDGPU data layout.
* Update AVX512 target feature handling. `evex512` is no longer used and `avx10.[12]-512` are now just `avx10.[12]`, matching the Rust feature name.
* Strip address space casts when emitting lifetime intrinsics. These are now required to directly work on the alloca.
r? @cuviper
As suggested, in order to distribute sanitizer instrumented standard
libraries without introducing new rustc flags, this adds a new dedicated
target. With the target, we can distribute the instrumented standard
libraries through a separate rustup component.
rustc_target: Remove unused Arch::PowerPC64LE
This variant has been added in https://github.com/rust-lang/rust/pull/147645, but actually unused since target_arch for powerpc64le- targets is "powerpc64". (The difference between powerpc64- and powerpc64le- targets is identified by target_endian.)
Note: This is an internal cleanup and does NOT remove `powerpc64le-*` targets.
Add `f16` inline ASM support for s390x
tracking issue: https://github.com/rust-lang/rust/issues/116909
cc https://github.com/rust-lang/rust/issues/125398
Support the `f16x8` type in inline assembly. Only with the `nnp-assist` feature are there any instructions that make use of this type. Based on the riscv implementation I now cast to `i16x8` when that feature is not enabled.
As far as I'm aware there are no instructions operating on `f16` scalar values. Should we still add support for using them in inline assembly?
r? @tgross35
cc @uweigand
Destabilise `target-spec-json`
Per rust-lang/compiler-team#944:
> Per https://github.com/rust-lang/rust/issues/71009, the ability to load target spec JSONs was stabilised accidentally. Within the team, we've always considered the format to be unstable and have changed it freely. This has been feasible as custom targets can only be used with core, like any other target, and so custom targets de-facto require nightly to be used (i.e. to build core manually or use Cargo's -Zbuild-std).
>
> Current build-std RFCs (https://github.com/rust-lang/rfcs/pull/3873, https://github.com/rust-lang/rfcs/pull/3874) propose a mechanism for building core on stable (at the request of Rust for Linux), which combined with a stable target-spec-json format, permit the current format to be used much more widely on stable toolchains. This would prevent us from improving the format - making it less tied to LLVM, switching to TOML, enabling keys in the spec to be stabilised individually, etc.
>
> De-stabilising the format gives us the opportunity to improve the format before it is too challenging to do so. Internal company toolchains and projects like Rust for Linux already use target-spec-json, but must use nightly at some point while doing so, so while it could be inconvenient for those users to destabilise this, it is hoped that an minimal alternative that we could choose to stabilise can be proposed relatively quickly.
