Adds two new Tier 3 targets - aarch64v8r-unknown-none{,-softfloat}
#150863
Conversation
|
Some changes occurred in src/doc/rustc/src/platform-support cc @Noratrieb Some changes occurred in tests/codegen-llvm/sanitizer cc @rcvalle These commits modify compiler targets. |
…8r-unknown-none-softfloat`. 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.
24ef519 to
61919a8
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
|
Ah, we've accidentally made |
|
r? @wesleywiser |
- line wrapping - extend the mapping of target_arch to llvm_component in tidy itself so it can handle target tuples that start with an aarch64v8r component - fix needs-llvm-component directive in `aarch64v8r` UI assembly test - extend `tests/assembly-llvm/targets/targets-elf.rs` as per target policy check
This comment has been minimized.
This comment has been minimized.
| stack_probes: StackProbeType::Inline, | ||
| panic_strategy: PanicStrategy::Abort, | ||
| default_uwtable: true, | ||
|
|
There was a problem hiding this comment.
Given the discussion around #149622, I wonder if these targets should be added with
| position_independent_executables: true, | |
| static_position_independent_executables: true, | |
since the consensus seemed to be that it would make sense for our existing aarch64 targets to be configured that way except it could break people already using the targets.
There was a problem hiding this comment.
We tried that and things broke (IIRC), so we wanted to (or you to) fix all the breakages in the existing target before we flipped that switch.
There was a problem hiding this comment.
We tried that and things broke (IIRC),
On this specfic point, as far as I could test the patch in #149622 breaks existing aarch64-unknown-none code that uses the aarch64-rt and/or the semihosting crate. This can be observed in this example: QEMU hangs and no output is printed; but the behavior can be observed in simpler programs as well.
As the AArch64 v8-R ISA builds on top of the Armv8.4-A ISA taking that patch has the same effect on this target.
3a967cb to
26db97d
Compare
|
There are comments above about "should this target include the changes in #149622". Reasons we should do this
Reasons we should not do this
My ProposalWe merge this target as-is, and we adjust #149622 to also patch these target, keeping them in sync. We can then work out what third-party crate changes are required and fix all four targets at the same time. The downside that this target would be static initially and change to be relocatable later will affect only a small number of people, and as the target is Tier 3 it can be subject to these kinds of changes anyway. Whatever announcements are made for the |
New Tier 3 targets -
aarch64v8r-unknown-noneandaarch64v8r-unknown-none-softfloatThis PR adds two new Tier 3 targets -
aarch64v8r-unknown-noneandaarch64v8r-unknown-none-softfloat.The existing
aarch64-unknown-nonetarget 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-softfloattarget allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existingaarch64-unknown-nonetarget 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.These targets are in support of firmware development on upcoming systems using the Arm Cortex-R82, particularly safety-critical firmware development. For now, it can be tested using the Arm's Armv8-R AArch64 Fixed Virtual Platform emulator, which we have used to test this target. We are also in the process of testing this target with the full compiler test suite as part of Ferrocene, in the same way we test
aarch64-unknown-noneto a safety-qualified standard. We have not identified any issues as yet, but if we do, we will send the fixes upstream to you.Ownership
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
Tier 3 Policy Notes
To cover off the Tier 3 requirements:
Arm will maintain this target, and I have presumed the Embedded Devices Working Group will also take an interest, as they maintain the existing Arm bare-metal targets.
We prefix this target with
aarch64because it generates A64 machine code (likearm*generates A32 andthumb*generates T32). In an ideal world I'd get to rename the existing targetaarch64v8a-unknown-nonebut that's basically impossible at this point. You can assumev6for anyarm*target where unspecified, and you can assumev8afor anyaarch64*target where not specified.It works just like the existing AArch64 bare-metal target.
Noted.
It's a bare-metal target, offering libcore and liballoc.
Done
AArch64 is a Tier 1 architecture, so I don't expect this target to cause any issues.
Noted.
It's AArch64 and so works with LLVM.