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

[Arnold Schwaighofer]

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

> On 7 June 2013 14:49, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
> 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).
> 
> Hi Arnold,
> 
> Can't the vectorizer not generate the v4f32 vectors in the first place, with that flag disabled?

No, vectorized floating point IR and non-vectorized floating point IR are semantically the same wrt to the end result - it is the backend that has to make sure that this is the case (scalarize if desired). The vectorizer is not the only one who could produce vectorize IR.

The vectorizer has two parts: legality and cost. It is legal to generate LLVM IR with vectors because they are semantically the same. The cost model should inform the vectorizer that it is a bad idea on ARM (after the backend has been fixed) because it will be scalarized (dependent on flags).

(I took the liberty to call vectorized IR, and scalar IR semantically the same, of course this only applies if you look at the execution not the individual instruction).


We don’t want to encode backend knowledge into the vectorizer (i.e. don’t vectorize type X because the backend does not support it). The only way to get this result is indirectly via the cost model but the backend must still support vectorized IR (it is part of the language) via scalarization.

(You can of course assign UMAX cost for all floating point vector types in the cost model for ARM and get the desired result - this won’t solve the problem if somebody else writes the vectorize LLVM IR though)


> 
> 
> 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.
> 
> This is one way of solving it, and maybe we will have to implement it anyway (for hand-coded IR or external front-ends).
> 
> However, that still doesn't solve the original issue. When the vectorizer analysis the cost of the new loop, it takes into account that now you have four operations (v4f32) instead of one, which is clearly profitable, but if we know that the back-end will serialize, than it's no longer profitable, and can quite possibly hurt performance.
> 
> I think we need both solutions.
> 
> cheers,
> --renato