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

Renato Golin via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 12 11:40:50 PST 2016


rengolin added a comment.

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.

> That's not an acceptable solution.  Darwin AArch32 specific documents that that subnormals are not supported on the platform, but users can and do expect that code compiled without an explicit -ffast-math will respect other floating point properties, such as preventing floating point reassociation.


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.

If Darwin doesn't support subnormals, then how can it use NEON? How can it use the vectorizer as it is, which produces NEON instructions?


Repository:
  rL LLVM

http://reviews.llvm.org/D17141





More information about the llvm-commits mailing list