3 Commits

Author SHA1 Message Date
Renato Golin
d30dbb6c8c [ARM] AArch32 v8 NEON is still not IEEE-754 compliant
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266603 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-18 12:06:47 +00:00
Vedant Kumar
891e9f4096 [test] Require 'asserts' for a test which uses -debug-only
Without this line, bots which run check-all on Release compilers will
break.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266386 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-14 23:32:40 +00:00
Renato Golin
a447ca5c09 [ARM] Adding IEEE-754 SIMD detection to loop vectorizer
Some SIMD implementations are not IEEE-754 compliant, for example ARM's NEON.

This patch teaches the loop vectorizer to only allow transformations of loops
that either contain no floating-point operations or have enough allowance
flags supporting lack of precision (ex. -ffast-math, Darwin).

For that, the target description now has a method which tells us if the
vectorizer is allowed to handle FP math without falling into unsafe
representations, plus a check on every FP instruction in the candidate loop
to check for the safety flags.

This commit makes LLVM behave like GCC with respect to ARM NEON support, but
it stops short of fixing the underlying problem: sub-normals. Neither GCC
nor LLVM have a flag for allowing sub-normal operations. Before this patch,
GCC only allows it using unsafe-math flags and LLVM allows it by default with
no way to turn it off (short of not using NEON at all).

As a first step, we push this change to make it safe and in sync with GCC.
The second step is to discuss a new sub-normal's flag on both communitues
and come up with a common solution. The third step is to improve the FastMath
flags in LLVM to encode sub-normals and use those flags to restrict NEON FP.

Fixes PR16275.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266363 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-14 20:42:18 +00:00