[LLVMdev] Vectorization: Next Steps

[Duncan Sands]

Hi Nadav,

> I also noticed cases where vector IR is scalariezd by the codegen.  From what I have seen (which is based on a different vectorizer with a different code model, etc) there are two main areas for improvements:
>
> 1. Complex instructions - Instructions such as shuffles are very sensitive to the ability of the codegen to lower them. If a vectorizer generates shuffle instructions which are not handled properly by the manual lowering code, then the instruction is scalarized.
>
> 2. Instructions with mixed types -Instructions which operate on mixed types, such as 2xfloat->2xdouble, are usually scalarized by the type legalizer.

yes, I was particularly thinking of the second type.  I think we should add some
debugging hooks to codegen so that we can easily see when this kind of thing is
happening.  I suspect that IR produced by the GCC vectorizer should never be
scalarized, because GCC only produces vector operations that are natively
supported (I could be wrong about this).  If so, any scalarization done by LLVM
on such IR represents a codegen deficiency.

Ciao, Duncan.

>
> Nadav
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands
> Sent: Friday, February 03, 2012 10:50
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Vectorization: Next Steps
>
> Hi Hal,
>
>> As some of you may know, I committed my basic-block autovectorization
>> pass a few days ago. I encourage anyone interested to try it out (pass
>> -vectorize to opt or -mllvm -vectorize to clang) and provide feedback.
>> Especially in combination with -unroll-allow-partial, I have observed
>> some significant benchmark speedups, but, I have also observed some
>> significant slowdowns.
>
> codegen for vector constructs is not always that great in my experience.
> It could be that your vectorizer is doing the right thing, and it's codegen that needs to be improved.  For example when I use the GCC autovectorizer I often see LLVM codegen unnecessarily scalarizing the vector code.  Did you try to analyse these slowdowns?
>
> Ciao, Duncan.
>
>    I would like to share my thoughts, and hopefully
>> get feedback, on next steps.
>>
>> 1. "Target Data" for vectorization - I think that in order to improve
>> the vectorization quality, the vectorizer will need more information
>> about the target. This information could be provided in the form of a
>> kind of extended target data. This extended target data might contain:
>>    - What basic types can be vectorized, and how many of them will fit
>> into (the largest) vector registers
>>    - What classes of operations can be vectorized (division,
>> conversions / sign extension, etc. are not always supported)
>>    - What alignment is necessary for loads and stores
>>    - Is scalar-to-vector free?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>