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

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 23 11:46:23 PST 2016

hfinkel added inline comments.

Comment at: include/llvm/Analysis/TargetTransformInfo.h:373
@@ +372,3 @@
+  /// and SLP vectorization without -ffast-math option.
+  bool isSIMDIEEE754() const;
What does one thing have to do with the other (i.e. what does IEEE floating point have to do with allowing fast-math)? The underlying issue is that, without fast-math, the numeric representation, and the operations on numbers in that representation, should be the same. fast-math allows the use of alternate representations and operations (so long as they're not too different), but also allows reassociation. To allow vectorizing reductions, we need reassociation as well (which is a separate matter from the potential change in operational semantics).

Comment at: lib/Target/ARM/ARMTargetTransformInfo.h:59
@@ +58,3 @@
+  // Darwin doesn't care about subnormals, so fast math is allowed everywhere.
+  bool supportsSubnormal() { return !ST->isTargetDarwin(); }
This comment seems misleading. "fast math" normally implies allowing things like reassociation (and lack of NaNs, etc.), and that has nothing to do with subnormals.

Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:1859
@@ +1858,3 @@
+             << "non-IEEE-754 compliant SIMD for this target. Use "
+                "-ffast-math or add #pragma clang loop vectorize(enable).");
+      emitMissedWarning(F, L, Hints);
This knowledge should live in the frontend. You can add proper diagnostic information subclass, and then catch it in the frontend to produce front-end specific information.


More information about the llvm-commits mailing list