Fix d32 usage in Arm target specs by adamgemmell · Pull Request #149512 · rust-lang/rust (original) (raw)

Fixes #149399 - after checking with an LLVM engineer Rust's feature implications do correctly map to LLVM's. The target specs originally had +vfp3,+d16, but were mistakenly fixed to +vfp3,-d32 which disables vfp3 again.

Some targets specify +vfp2,-d32, and since vfp2 shouldn't imply d32 the -d32 is unneeded.

The list of Arm features is quite old and since Arm is now a target maintainer of many of them we'll go in and update them. We should probably add vfp3d16 and similar as rust has no way to express these right now after d16 was removed.

The LLVM features expand like this:

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

-neon might be unnecessary too in many of these cases, but some default CPUs that Rust specifies will turn Neon on so that needs a bit more care. I can't see any LLVM cpus that enable D32.

Old description:

Fixes #149399 - this implication was likely a mistake and isn't enforced by LLVM. This is is a breaking change and any users specifying vfp2/3/4 via -Ctarget-features or the target_feature attribute will need to add d32 in to get the same behaviour. The target features are unstable so this is ok for Rust, and this is necessary as otherwise there's no way to specify a vfp2-d16 configuration, for example.

I expect these targets would have been broken by #149173 as -d32 would have disabled any +vfpX feature before it. With the removal of the implication the -d32 went back to being unnecessary, but I've removed it anyway.

As @RalfJung pointed out, thumbv7a-nuttx-eabihf looks to have been relying on this implication so I've added +d32 to it's target spec.