[llvm-dev] Vectorization with fast-math on irregular ISA sub-sets
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 11 02:53:09 PST 2016
I had a read on the ARM ARM about VFP and SIMD FP semantics and my
analysis is that NEON's only problem is the Flush-to-zero behaviour,
which is non-compliant.
NEON deals with NaNs and Infs in the way specified by the standard and
should not cause any concern to us. But we don't seem to have a flag
specifically to denormals, so I think using the UnsafeMath is the
safest option for now.
On 11 February 2016 at 01:15, Hal Finkel <hfinkel at anl.gov> wrote:
> No Signed Zeros - Allow optimizations to treat the sign of a zero argument or result as insignificant.
In both VFP and NEON, zero signs are significant. In NEON, the
flush-to-zero's zero will have the same sign as the input denormal.
> No NaNs - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to retain defined behavior over NaNs, but the value of the result is undefined.
Both VFP and NEON treat NaNs as the standard requires, ie. [ NaN op ? ] = NaN.
> No Infs - Allow optimizations to assume the arguments and result are not +/-Inf. Such optimizations are required to retain defined behavior over +/-Inf, but the value of the result is undefined.
Same here. Operations with Inf generate Inf or NaNs on both units.
The flush-to-zero behaviour has an effect on both NaNs and Infs, since
it happens before. So a denormal operation with an Inf in VFP will not
generate a NaN, while in NEON it'll be flushed to zero first, thus
James, is that a correct assessment?
More information about the llvm-dev