This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Emit Tag_ABI_FP_denormal correctly in fast-math mode.
ClosedPublic

Authored by chatur01 on Nov 27 2014, 6:52 AM.

Details

Reviewers
t.p.northover
Summary

The default ARM floating-point mode does not support IEEE 754 mode exactly. Of relevance to this patch is that input denormals are flushed to zero. The way in which they're flushed to zero depends on the architecture,

  • For VFPv2, it is implementation defined as to whether the sign of zero is preserved.
  • For VFPv3 and above, the sign of zero is always preserved when a denormal is flushed to zero.

When hardware FP support has been disabled, the strategy taken by this patch is to assume the software support will mirror the behaviour of the hardware support for the target *if it existed*. That is, for architectures which can only have VFPv2, it is assumed the software will flush to positive zero. For later architectures it is assumed the software will flush to zero preserving sign.

The reason the current behaviour is wrong is because IEEE 754 support is enabled by default when using -ffast-math. In such a mode we should indicate we're flushing denormals according to the rules explained above.

As an aside in the test file, the reason I have chosen to have a <CPU NAME>-FAST check prefix for each CPU name, rather than to create a just a couple extra prefixes for denormals and tack them onto each command-line check is that there will be more tests for build attributes in fast maths mode, so these check prefixes won't be checking just one attribute for very long.

Diff Detail

Event Timeline

chatur01 retitled this revision from to [ARM] Emit Tag_ABI_FP_denormal correctly in fast-math mode..
chatur01 updated this object.
chatur01 edited the test plan for this revision. (Show Details)
chatur01 set the repository for this revision to rL LLVM.
chatur01 added a subscriber: Unknown Object (MLST).

Hi Charlie,

So where do we make these assumptions, or is this patch setting out a set of plans for the future? It's mostly curiosity, I don't remember seeing any code even mentioning denorms in my LLVM travels.

Cheers.

Tim.

Hi Tim,

So where do we make these assumptions, or is this patch setting out a set of plans for the future? It's mostly curiosity, I don't remember seeing any code even mentioning denorms in my LLVM travels.

Which assumptions are you referring to? Perhaps the various "We default to IEEE 754 compliance" comments sprinkled in the test file? I assumed that's the default based on the original behaviour of LLVM (this tag is unconditionally set to 1 when we're not in unsafe maths mode). It's also what armcc does in ieee_full mode. Another assumption I'm making is that our default level of IEEE compliance is intended to mirror that of GCC. Whether that's currently the case is another matter, but it appears to be the goal.

The values for the unsafe maths mode are based off whether the target has an FPU, and if so what the behaviour of flush-to-zero is for the respective FP unit.

This work is only of interest to FP library selection.

Thanks a lot for taking a look!
Charlie.

t.p.northover accepted this revision.Dec 1 2014, 10:40 AM
t.p.northover added a reviewer: t.p.northover.

Fair enough, I think that makes sense. Go for it!

Tim.

This revision is now accepted and ready to land.Dec 1 2014, 10:40 AM

Thank you Tim, committed as r223110.