llvm dev - May 2013 - [LLVMdev] LLVM Loop Vectorizer puzzle

On May 23, 2013, at 8:06 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> 
>> 
>> 
>> Hi,
>> 
>> Just from personal interest, is there a canonical way in IR+metadata
>> to express "This small constant trip-count loop is desired to be
>> converted into a sequence of vector operations directly"? Ie,
>> mapping a 4 element i32 loop into a linear sequence of <4 x i32>
>> operations. Obviously this may not always be a win, but I'm just
>> wondering if there's a way to communicate this intent and get
around
>> the vectorizer-min-trip-count in specially desired cases, or if I
>> should decide to generate vectorized IR directly. (This is in code
>> coming from a DSL which will impliciltly insert annotations, not
>> manually written loops.)
>> 
> 
> I think that the answer is: not currently. On the other hand, if the loop
is small enough to get unrolled, then you can either use the BB vectorization
pass or the SLP vectorization pass to vectorize it.
Yes.

I would like us to grow a few annotations, among others, one to force
vectorization irrespective whether the loop vectorizer thinks it is beneficial
or not - however, this is future music.

On 23 May 2013 14:52, Arnold Schwaighofer <aschwaighofer at apple.com>
wrote:
> I would like us to grow a few annotations, among others, one to force
> vectorization irrespective whether the loop vectorizer thinks it is
> beneficial or not - however, this is future music.
>
Isn't that part of the ivdep implementation? I thought there was support
for that already...

--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/213e6e2c/attachment.html>

On May 23, 2013, at 9:15 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 23 May 2013 14:52, Arnold Schwaighofer <aschwaighofer at
apple.com> wrote:
> I would like us to grow a few annotations, among others, one to force
vectorization irrespective whether the loop vectorizer thinks it is beneficial
or not - however, this is future music.
> 
> Isn't that part of the ivdep implementation? I thought there was
support for that already...
No, llvm.loop.parallel only communicates information about memory dependencies
(or there absence of) and the loop vectorizer only uses it for this. I don’t
think we should give it additional semantics of forcing vectorization.

Of course, you could locally patch llvm to abuse it for other purposes...


(Note, I have not formed a strong opinion on this yet, these are just some
initial thoughts, I am not convinced yet that the attributes below are the right
set of attributes, or that the syntax is right ;)

I am thinking of something like:

llvm.vectorization.<param><value>


where which would allow us to safety and optimization parameters from the front
end:


- Safety:
 #pragma vectorize [max_iterations <NUM>]

 For vectorization we might want to have an optional parameters at which
distance vectorization is safe:
 #pragma vectorize max_iterations 8
 would indicate that vectorization up to a distance 8 is safe. This would
restrict the combinations of VF and unroll factor the vectorizer is allowed to
choose.

- Parameters controlling the vectorizer optimization choices:
 width, unroll factor, force vectorization at Os, don’t vectorize

#pragma vectorize width 4 unroll 2
Forces VF=4 and unroll=2

#pragma vectorize max_iterations 8
Allows the vectorizer to choose.

#pragma vectorize off
Disable vectorization.

#pragma vectorize force


If we decide, that

#pragma ivdep

should imply forced vectorization (which I am not sure it should), the front-end
can than in addition to the llvm.loop.parallel metadata, emit meta data to force
vectorization. But, I don’t think we should overload the semantics of
llvm.loop.parallel.