Remove d32 feature from 32-bit Arm targets

[adamgemmell]

Fixes #159973

In #149512 I removed -d32 from some specs, but since LLVM enables neon by default for v7 targets d32 was left enabled while it should be optional on this target. For a similar reason -d32 was removed from some armv6 targets and has been readded.

This PR adds a test to ensure this specific instance does not happen again and has been tested locally on armv7-unknown-linux-gnueabihf, armv7a-none-eabihf and arm-unknown-linux-gnueabihf.

It might be a good idea in general to have a test that runs --print cfg and captures the set of rust target features enabled to show when PRs change them, but most of these targets are not run in Rust's CI so it's out of scope for this issue.

For reference, here is the manually-expanded LLVM features and their implications - necessary as these targets rely on a feature from LLVM that Rust doesn't yet expose:

vfp4 -> vfp3 + fp16 + vfp4d16 + vfp4sp
vfp4d16 -> vfp3d16 + fp16 + fp64 + vfp4d16sp
vfp4sp -> vfp3sp + fp16 + d32 + vfp4d16sp
vfp4d16sp -> vfp3d16sp + fp16
vfp3 -> vfp2 + vfp3d16 + vfp3sp
vfp3d16 -> vfp2 + fp64 + vfp3d16sp
vfp3sp -> vfp2 + d32 + vfp3d16sp
vfp3d16sp -> vfp2sp
vfp2 -> vfp2sp + fp64
vfp2sp -> fpregs

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 18 candidates

[thejpster]

Why are the T32 and A32 targets different? Could we leave a note here to explain that?

View changes since the review

[adamgemmell]

Fixed this

[RalfJung]

but since LLVM enables neon by default for v7 targets d32 was left enabled while it should be optional on this target

What does neon have to do with d32? Is there some implication here? And does that mean disabling d32 also disables neon?

[adamgemmell]

but since LLVM enables neon by default for v7 targets d32 was left enabled while it should be optional on this target

What does neon have to do with d32? Is there some implication here? And does that mean disabling d32 also disables neon?

neon implies vfp3 implies d32. So yes -d32 disables neon, I've simplified the specs to account for that. What confused me is that LLVM does not do this behaviour on its own, so implications that rust doesn't model do not behave in this way. An example that I tried for this PR was starting with -fpregs to give make the FPU features a clean slate.

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[RalfJung]

We can have "neon" imply "fpregs" on the Rust side I think, if the target maintainers think that's a good idea. (Or I guess it would be vfp2 -> fpregs?)

[thejpster]

I built the branch, and the cfg changes check out:

$ diff <(RUSTUP_TOOLCHAIN=nightly rustc --print cfg --target armv7a-none-eabihf) <(RUSTUP_TOOLCHAIN=stage1 rustc --print cfg --target armv7a-none-eabihf)
11d10
< target_feature="d32"
23d21
< target_feature="vfp3"
$ diff <(RUSTUP_TOOLCHAIN=nightly rustc --print cfg --target thumbv7a-none-eabihf) <(RUSTUP_TOOLCHAIN=stage1 rustc --print cfg --target thumbv7a-none-eabihf)
11d10
< target_feature="d32"
24d22
< target_feature="vfp3"

LGTM.

[adamgemmell]

We can have "neon" imply "fpregs" on the Rust side I think, if the target maintainers think that's a good idea. (Or I guess it would be vfp2 -> fpregs?)

vfp2 -> fpregs is probably what I'll do yeah - we're currently planning to look at arm target features next quarter.