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

[Renato Golin via llvm-commits]

rengolin added inline comments.

================
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);
----------------
hfinkel wrote:
> rengolin wrote:
> > hfinkel wrote:
> > > 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.
> > Which knowledge?
> > 
> > AFAICS, SIMD IEEE compliance should not be in the front-end, neither should be Darwin's compliance.
> > 
> > The way I'm handling in the loop vectorizer is the same as with other restrictions, and it shouldn't affect SLP or other transformations, so moving this to the front-end will impact everything, not just this specific case.
> The knowledge of which front-end flags (-ffast-math) and pragmas can change the behavior belongs in the frontend. The messages we send from the backend are often strings, but can be message subclasses that the frontend can interpret to provide  frontend-specific information along with that provided by the back end. (I'll happily provide more details if you'd like when. I'm not working off my phone).
Right, I think we're going off track here. I was trying to be helpful, but I can change it to just say the SIMD is not IEEE compatible and I can't vectorize unless the user requests floating-point relaxation, and leave -ffast-math as an exercise to the reader.

Is that what you meant?


http://reviews.llvm.org/D17141