[PATCH] Implement pragma llvm.vectorizer.enable in LoopVectorizer

[Arnold]

Sent from my iPhone

>> On Nov 29, 2013, at 6:03 AM, Renato Golin <renato.golin at linaro.org> wrote:
>> 
>> On 29 November 2013 04:19, Nadav Rotem <nrotem at apple.com> wrote:
>> The semantics that you propose for ‘enable’ is that it will tell the vectorizer to select any legal vectorization factor that is not 1. Right?
> 
> This is one of the two semantics I want for "enable", yes.
> 
> 
>> I would like to propose a slightly different semantic for this pragma. I think that people who care about vectorization would like to do one of following:
>> 
>> 1. Tell the compiler to enable vectorization on this part of the code, even if vectorization is disabled via -Oz, etc.
> 
> This is the other semantics, which I'll implement next.
> 
> If the vectorizer is enable, I want to be able to force the
> vectorization of loops even if the cost analysis say it's not worth
> it. If the vectorizer is not enabled, I want to enable it and
> vectorize this loop, also no matter the cost.


But at which width/factor? If the cost model "fails" how should the vectorizer select "the right" one? (This case is covered by pragma width/unroll)

I think #pragma vectorizer enable should just turn on vectorization with automatic selection of the VF/UF.

You also would not need new meta data for this llvm.vectorizer.unroll (0) and llvm.vectorizer.width(0) already have this semantics.

To implement Oz and O1 vectorization we would pass a flag to the loop vectorizer to only vectorize loops marked with the right metadata.

At Os we take these flags to mean vectorize with O3 heuristics.

Alternatively, "pragma vectorize enable" would enable vectorization of the best vector factor, even if its cost is worse than the scalar costs.

I am not sure that this would be the better alternative, though. (In this case we would  need a new metadata flag). I think in cases where the cost model fails we want the user to specify the vectorization width via a pragma.

> This is why I think these two behaviours are related.
> 
> 
>> 2. Tell the compiler that it is safe to vectorize this loop (and let the compiler choose the best vector width and unroll factor).
> 
> Safety pragmas will be the next bundle. I want to get the basics first.
> 
> 
>> 3. Tell the compiler the exact vector width and unroll factor.
> 
> Yes, these are already available in the vectorizer as metadata, we
> just need to implement it in Clang.
> 
> Once I have all four behaviours implemented in LLVM via metadata, I'll
> implement the three pragmas in Clang.
> 
> 
>> I think that it makes sense to make ‘enable’ control #1, which means that this pragma needs to enable vectorization regardless of the compiler flags or other size-related heuristics.  I don’t think that this pragma should control the vectorization width or unroll factor.
> 
> Agree. This is why I made the VF selector to pick the best vectorization factor.
> 
> cheers,
> --renato
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits