[LLVMdev] Vectorization: Next Steps
hfinkel at anl.gov
Fri Feb 3 05:56:46 PST 2012
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
> 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
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev