[LLVMdev] Vectorization: Next Steps

[Hal Finkel]

On Fri, 2012-02-03 at 09:49 +0100, Duncan Sands wrote:
> 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?

There are a lot of them and I've only looked at a small fraction as of
yet. I have seen things that look like codegen deficiencies, but I've
not confirmed this in detail. One important case that I have noticed is
where the pass will vectorize sign-extended conversions, or int/float
conversions, etc. which end up being expensive to scalarize. There are
also cases where it vectorizes small integer operations which just get
scalarized by the codegen. I need to spend some more time looking at
this.

 -Hal 

> 
> 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

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory