[LLVMdev] Loop vectorizer

Rao, Shivarama Shivarama.Rao at amd.com
Tue Oct 16 19:06:17 PDT 2012

Hi Nadav,

Do you have any small write-up of current design of loop vectorizer?. If so, can you please send it across?. I want to see if there are dependencies such as unrolling for the vectorization. 

In the design we may also have to consider BB vectorizer and loop vectorizer working well together with no ambiguous requirements/dependencies.   


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel
Sent: Wednesday, October 17, 2012 4:02 AM
To: Nadav Rotem
Cc: preston briggs; llvmdev at cs.uiuc.edu List
Subject: Re: [LLVMdev] Loop vectorizer

----- Original Message -----
> Hi Preston!
> >
> > I'd start by making a plan (a design!) with goals and stuff.
> > Publish it so we can see what you mean by "vectorization".
> I will send a separate email later, but here is a quick overview. I
> see the vectorizer having four main components:
> 1. Preparation passes: If-conversion, loop transformations, etc.
> 2. Cost model - This unit decides on the best vectorization factor
> (could be 1).
> 3. Legality check - This unit checks if it is *legal* (from a
> correctness point of view) to vectorize the program. This is target
> independent. Also, this unit needs to describe which transformation
> are needed to make this loop vectorizeable. For example: if-conversion
> is required if the control flow is not uniform for all iterations of
> the loop.
> 4. Vectorization - This is where the actual widening of the
> instructions happen. Every time we improve #3 by detecting more
> vectorizeable loops, we need to add the mechanism for actually
> generating code for it. For example, we can detect reduction
> variables, but we also need to be able to generate code for them.
> > I.e., do you mean for real vector machines, a la Cray, or for
> > the packed media instructions that are currently so popular?
> I am mostly interested in generating code for the popular SIMD cpus
> (X86, ARM, PPC, etc).
> > What's your idea for finding vectorizable loops?
> I started with a very very basic check because I needed to start
> somewhere. We will need to design a mode advanced check.
> > Do you have a plan for xforms to increase the amount of
> > vectorization?
> Yes. We will need to implement a predication phase and to design the
> interaction with other loop transformations. Also, this will have to
> work well with the cost model. We also need to think of a good way to
> detect early on if the transformations are likely to be effective,
> because we currently don't have a good way of undoing compiler
> transformations.
> I think that a simple if-converter will be a good place to start. What
> do you think ?

Quick comment: IIRC, Ralf Karrenberg has already implemented this (as part of his WVF project: https://github.com/karrenberg/wfv/tree/llvm_30). It might be worthwhile to work on cleaning up his implementation instead of starting from scratch.


> > I've written a dependence analyzer that ought to be suitable
> > (if it isn't, we should fix it).
> I know :) Yes, this is really good. Any serious loop transformation
> and multi-dimentional array vectorization will need this. I am glad
> that you are working on this and I do want to use it.
> In the near future, I plan to work on the code generation cost-model
> aspects.
> The vectorization legality check that I wrote is very simple and very
> conservative. It will be great if you could contribute in that area.
> Thanks,
> Nadav
> >
> > Thanks,
> > Preston
> _______________________________________________
> 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
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu

More information about the llvm-dev mailing list