[llvm-commits] [llvm] r154735 - in /llvm/trunk: lib/Transforms/Vectorize/BBVectorize.cpp test/Transforms/BBVectorize/no-ldstr-conn.ll

Hal Finkel hfinkel at alcf.anl.gov
Sat Apr 14 09:59:47 PDT 2012



----- Original Message -----
> From: "Duncan Sands" <baldrick at free.fr>
> To: llvm-commits at cs.uiuc.edu
> Sent: Saturday, April 14, 2012 12:53:58 PM
> Subject: Re: [llvm-commits] [llvm] r154735 - in /llvm/trunk: lib/Transforms/Vectorize/BBVectorize.cpp
> test/Transforms/BBVectorize/no-ldstr-conn.ll
> Hi Hal,
> 
> > Fix an error in BBVectorize important for vectorizing pointer types.
> >
> > When vectorizing pointer types it is important to realize that
> > potential
> > pairs cannot be connected via the address pointer argument of a load
> > or store.
> > This is because even after vectorization, the address is still a
> > scalar because
> > the address of the higher half of the pair is implicit from the
> > address of the
> > lower half (it need not be, and should not be, explicitly computed).
> 
> I guess this is a limitation of LLVM's vector support: if the argument
> to a
> load was a vector of pointers (the result being the vector of loaded
> values)
> then this wouldn't be needed, right?

In this case, I don't think so. This is just a side effect of that fact that vectorized loads and stores are special. For most instructions, vectorizing them means changing them from taking 1 input to taking N inputs. Each of those N inputs still needs to be computed (hopefully, with another vectorized operation if that is possible). With loads and stores, vectorizing them does not change the number of addresses they take, each still needs only one. The other addresses are now implicit in the one remaining base address. This is already a special case, and this special case had just not been completely accounted for.

We may, in the future, wish to support vectorized loads and stores which do take a vector of pointers. I suppose the only question there is: is this supported in any useful sense on real hardware? To the best of my knowledge, the answer is no, but maybe there are ISAs with scatter/gather vector load/store instructions of some kind.

> 
> In fact, maybe you should make a list of any irregularities you notice
> in LLVM's
> vector support in view of improving the IR language in the future.

I will.

Thanks again,
Hal

> 
> Ciao, Duncan.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



More information about the llvm-commits mailing list