[LLVMdev] NEON vector instructions and the fast math IR flags

Arnold Schwaighofer
Fri, 07 Jun 2013 13:49:11 -0000

On Jun 7, 2013, at 3:14 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 7 June 2013 08:48, Tobias Grosser <tobias at grosser.es> wrote:
> When to set which subtarget feature is a policy decision, where I honestly
don't have any opinion on for clang. The best is probably to mirror the gcc
behavior on linux targets.
>
> Not really, since GCC has no special behaviour for Darwin, AFAIK.
>
> My change will only generate SP-FP on NEON for A5 and A8 and only if
it's Darwin or UnsafeMath is on, which seems not to be the case for you, so
I don't think the problem is in that area. It's possible that some
passes are not consulting that flag when generating NEON SP-FP. If that's
true, this is definitely a bug.
>
> When I changed that, for VMUL.f32, it worked (ie. generated VFP
instruction), but it might not be taking the same path your code is.
>
>
> I just looked again at the +neonfp flag. Compiling with and without +neonfp
flag seems to only affect scalar types in the attached test case. If e.g. the
LLVM vectorizer introduces vector instructions on LLVM-IR level floating point
vectors still yield NEON assembly even if compiled with
"-mattr=+neon,-neonfp". Is this expected?
>
> No, vectorizers should honour FP contracts. This is probably a bug, too.
>
> Please, fill both bugs on bugzilla, attaching the relevant IR to each one
and a way to reproduce, and I'll have a look at them.
>


It is not the vectorizer that is the issue, it is the ARM backend that currently
translates vectorized floating point IR to NEON instructions (it should
scalarize it if desired to do so - i.e. if people care about denormals). To fix
this issue one would have to fix the backend: i.e not declare v4f32 et al as
legal (under a flag). As to making this predicated on fast math flags on
operations (something like no-denormals - i don’t think we have that in the IR
yet - we only have no nan, no infinite, no signed zeros, etc) I believe this
would be a lot harder because I suspect you would have to custom lower all the
operations.


> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev