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

[Tobias Grosser]

On 06/07/2013 06:49 AM, Arnold Schwaighofer wrote:
>
> 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.

Thanks for that explanation. I think it illustrates the situation well.

For programs that have mixed precision requirements for floating point 
operations we probably need to do this according to the fast math flags.
Until we get there, a good first step would probably be to provide a 
global option similar to -enable-no-infs-fp-math that specifies if 
denormals should be allowed or not. This would allow the user to specify 
the precision requirements, without the need to alter with the feature 
flags of a specific piece of hardware.

Tobi