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 Jan 26 2018, 2:11 AM.

Details

Summary

This change was orignally approved in Differential Revision
https://reviews.llvm.org/D40256 and committed in r319420 and subsequently
reverted in r319425.

The problem was identified due to creating a local string which was placed
in a vector used by the calling function resulting in undefined behaviour;
this revised patch fixes this issue with a call to Args.MakeArgString()
and updates the test results due to the fix (order of expected options
changed requiring more matching patterns) and other changes affecting
the tests since this issue was previously approved (macro hex constants
changing case). Due to the number of changed lines in the tests I though
I should get this change re-reviewed and approved.

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
rL LLVM

Event Timeline

compnerd accepted this revision.Feb 5 2018, 5:08 PM
This revision is now accepted and ready to land.Feb 5 2018, 5:08 PM

review request ping.

There was one line in the compiler itself which is different to what had been previously reviewed and approved ... so hopefully that change is easily reviewed.

However this change also resulted in updates to the associated tests, and the size of these test changes were the reason why I had put the change up for review again. The changes are mainly due to the order of the options being tested changing slightly.

This revision was automatically updated to reflect the committed changes.