[PATCH] D17141: [ARM] Adding IEEE-754 SIMD detection to loop vectorizer

[Owen Anderson via llvm-commits]

resistor added a comment.

In http://reviews.llvm.org/D17141#351645, @rengolin wrote:

> In http://reviews.llvm.org/D17141#351607, @resistor wrote:
>
> > It *does* depend on the OS running underneath, and I'm providing an example right here. This is comparable to the fact that many implementations do not provide sNaN support.
>
>
> I'm not sure I understand. Are you talking about Apple's implementation of the SIMD unit, or about the OS setting up some different flags?
>
> AFAIK, you can't "turn on" IEEE compliance on NEON with hardware flags. So, if you accept non-IEEE-compliant code in Darwin (the OS?) becomes a platform decision, not a hardware requirement. This flag is about the hardware requirement.


Darwin, as a policy, maps all floating point onto the NEON unit.  As you point out, this discards some elements of IEEE conformance, with subnormal support being the one that is typically brought.  Darwin documents this as the correct behavior of the platform, even without -ffast-math.

> Now I'm even more confused. The purpose of fast-math is to relax the FP model, not restrict it. I'm not relaxing more than before, I'm restricting it more.


Yes, and restricting it in the way you propose will introduce significant regressions on Darwin.  Darwin wants to perform floating point vectorization, even without -ffast-math, provided that the actual constraints like no reassociation are respected.  In other words, the reasoning you present here that the NEON unit can only be used with -ffast-math is not true for Darwin.


Repository:
  rL LLVM

http://reviews.llvm.org/D17141