This is an archive of the discontinued LLVM Phabricator instance.

[ARM] disable FPU features when using soft floating point.
ClosedPublic

Authored by keith.walker.arm on Nov 20 2017, 8:54 AM.

Details

Summary

To be compatible with GCC if soft floating point is in effect any FPU
specified is effectively ignored, eg,

-mfloat-abi=soft -fpu=neon

If any floating point features which require FPU hardware are enabled
they must be disable.

There was some support for doing this for NEON, but it did not handle
VFP, nor did it prevent the backend from emitting the build attribute
Tag_FP_arch describing the generated code as using the floating point
hardware if a FPU was specified (even though soft float does not use
the FPU).

Disabling the hardware floating point features for targets which are
compiling for soft float has meant that some tests which were incorrectly
checking for hardware support also needed to be updated. In such cases,
where appropriate the tests have been updated to check compiling for
soft float and a non-soft float variant (usually softfp). This was
usually because the target specified in the test defaulted to soft float.

Diff Detail

Repository
rC Clang

Event Timeline

-mfpu controls what floating-point/vector instructions the compiler generates. -mfloat-abi controls whether floating-point arguments to functions are passed in floating-point registers. These are completely independent, and we need to support using both of them together to generate NEON code with a soft-float ABI. (Android is built like this.)

rengolin edited edge metadata.Nov 20 2017, 1:20 PM

Wasn't that the mess about -mfpu=softfp?

It would have been much cleaner if it worked as @efriedma suggests and -mfloat-abi was only concerned with the ABI (as its name would suggest), but sadly the -mfloat-abi=soft option seems to be defined in GCC to control more than just the ABI.

Adding llvm-commits to the subscriber list.

Oh, I see, for some silly reason there are actually *three* -mfloat-abi options: hard, soft, and softfp. hard means float instructions and a hard-float calling convention, soft means no floating-point and a soft-float convention, and softfp means float instructions and a soft-float convention. This is probably worth clarifying with a comment.

lib/Driver/ToolChains/Arch/ARM.cpp
405

I don't like explicitly enumerating the features like this; it'll mess up if there's ever a new feature which isn't explicitly enumerated here. Can we just do Features.push_back("-vfpv2") and depend on that to implicitly disable all the other vfp features?

compnerd added inline comments.Nov 20 2017, 5:43 PM
lib/Driver/ToolChains/Arch/ARM.cpp
401

Similar.

418

It would be nice to not have these explicitly listed. But at the very least, I think that having a list and looping through it would be better:

for (const auto Feature : {"vfpv2", "vfpv3", "vfpv4", "fp-armv8", "fullfp16"})
  if (std::find(std::begin(Features), std::end(Features), "+" + Feature) == std::end(Features))
    continue;
  else
    Features.push_back("-" + Feature);
lib/Driver/ToolChains/Arch/ARM.cpp
405

I'll check on whether disabling a feature on which other features depend automatically disables the other features is something that can be relied upon (It would seem sensible that one could .... but need to check).

That would certainly mean the code could be simplified, although I would also need to check the impact on the what is checked in the testing (only test for the base feature being disabled because the dependent features are automatically disabled).

418

This certainly looks a better way to do it if we do need to provide a list of features rather than relying on disabling a base feature on which the other features depend.

I have updated the patch with the suggested change to use a list of features to disable.

I checked that LLVM does indeed implicitly disable features if they are dependent on a feature that is explicitly disabled, so in theory we
could just disable "vfp2" and "neon". However I found that this made the tests in clang more difficult to write and understand.

For example if a test wants to check that "dotprod" is not enabled:

  • with the explicit disabling the check can be: CHECK-NO-DOTPROD-NOT: "--target-feature" "+dotprod"
  • with implicit disabling the check needs to be something like: CHECK-NO-DOTPROD: "--target-feature" "+dotprod" CHECK-NO-DOTPROD: "--target-feature" "-neon"

I think this made the tests harder to understand as there is more implicit knowledge required to understand what is going on.

For this reason I have gone for still explicitly disabling the dependent FP features, with a FIXME so that this could be improved in the future.

keith.walker.arm marked 5 inline comments as done.Nov 27 2017, 3:12 AM
efriedma added inline comments.Nov 27 2017, 2:22 PM
test/Driver/arm-mfpu.c
301

What are these disabled "R-UN" lines?

Do we really need to check every combination like this? I don't think the underlying logic actually varies.

What are these disabled "R-UN" lines?

Oops! They shouldn't have been disabled in the patch.

Do we really need to check every combination like this? I don't think the underlying logic actually varies.

I have reduced the tests in the part to do a check against each architectural variant, and then just one check with the different -msoft-float/-mfpu=none options.

This revision is now accepted and ready to land.Nov 29 2017, 12:42 PM
This revision was automatically updated to reflect the committed changes.