[llvm-dev] Vectorization with fast-math on irregular ISA sub-sets

[James Molloy via llvm-dev]

Hi,

> James, is that a correct assessment?

Yes, it is also my belief that the only way ARMv7 NEON differs from IEEE754 is lack of denormal support.

James

> On 11 Feb 2016, at 10:53, Renato Golin <renato.golin at linaro.org> wrote:
> 
> Hal,
> 
> 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:
>>  nsz
>>  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.
> 
> 
>>  nnan
>>  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.
> 
> 
>>  ninf
>>  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
> generating NaNs.
> 
> James, is that a correct assessment?
> 
> cheers,
> --renato
>