[LLVMdev] GSoC 2009: Auto-vectorization

Andreas Bolka andreas.bolka at gmx.net
Wed Apr 1 12:50:08 PDT 2009


Hi Stefanus,

On Wed Apr 01 16:08:45 +0200 2009, Stefanus Du Toit wrote:
> On 31-Mar-09, at 8:27 PM, Andreas Bolka wrote:
> > i.e. the core of the desired result would look like:
> >
> >    %va = load <256 x i32>* %a
> >    %vb = load <256 x i32>* %b
> >    %vc = add <256 x i32> %a, %b
> >    store <256 x i32> %vc, <256 x i32>* %c
>
> I think the biggest problem with this approach, apart from the fact
> that it doesn't mirror how vectors are typically used today in LLVM,
> is that vectors in LLVM are of fixed size. This is going to severely
> limit the usefulness of this transformation. I think you may be better
> off getting information about vector widths for the architecture (e.g.
> from TargetData) and vectorizing directly with a particular width in
> mind.

Thanks for the remark. My initial thinking was that, independent of
auto-vectorization, a general "wide vector strip-mining" transformation
would be worthwhile to have anyway. I.e. a transformation which would
convert such wide vector operations as above to a loop over
(target-dependent) smaller width vectors. And as the auto-vectorizer I
am aiming for would initially only be able to vectorize loops with
statically known constant trip counts, I could squash some complexity by
leaving this target-dependent aspect to such a hypothetical strip-mining
pass.

But I understand the limits of this, and based on the feedback I got so
far, I'll rather generate a loop with fixed-size vectors instead. A
command-line option to determine the vectorization factor should do fine
to enable quick bootstrapping, if querying the necessary register width
from TargetData turns out to be problematic.

> Overall, this would be a great GSOC project, and I guarantee you would
> get a lot of interest in this :). Good luck!

Thanks!

-- 
Andreas



More information about the llvm-dev mailing list