[LLVMdev] LLVM Loop Vectorizer (Nadav Rotem)

[Tobias Grosser]

On 10/08/2012 06:02 AM, Nadav Rotem wrote:
> Hi Javed,
>
> Developing a good loop vectorizer takes several years.  The work on the GCC vectorizer began in 2004, and they spent several years improving and optimizing their vectorizer.  They started by vectorizing simple loops, and added features that they needed in order to vectorize additional loops that were important for them.  They started with a single-block loops, and later they added "if-conversion", support for reductions and induction variables, etc.  This approach was effective because it allowed them to stay focused.
>
> It is important to stay focused on today's problems, but at the same time provide the right abstraction even for problems that we decide not to solve today. We've started discussing the details of exposing target information to IR-level passes because it will allow the loop vectorizer, as well as other optimizations, to do a better job.  Once we finish the design of the "Target" interface, we need to start working on a general loop-vectorizer design.  I think that any design that we choose must take Polly into consideration.  But I don't think that we need to start with loops that require polyhedral optimizer. I think that we should start with the examples from the gcc vectorizer page[1].

Hi Nadav, Javad,

yes, I think the path you are taking is great. The 'Target' interface 
was one of immediate problems for vectorization. Solving it will help 
any pass working in that area.

Regarding the use of Polly as a loop vectorizer. Polly is definitely a 
tool that may help in the area of loop vectorization, but as Nadav said, 
its use must be carefully evaluated. I see Polly rather as a piece of a 
bigger picture, then the one and only solution to vectorization in LLVM.

I think Pollys strengths are definitely in the area of loop 
transformations. In case we want to do outer loop vectorization, require 
interchange, strip-mining, ... to enable vectorization or want to create 
cleanup loops, Polly can be of great value. However, vectorization is 
also a lot of pattern matching on IR level. I am not sure if all this 
pattern matching really needs to be part of a polyhedral optimizer. My 
personal feeling is that we would be better of keeping this separate.

Also, as Nadav pointed out, as a first step a vectorizer will probably 
focus on very simple loops. Polly can obviously also help to vectorize 
them, but Polly may or may not be too much overhead for such simple 
cases. I think Sebastian Pop actually tested Polly on the gcc vectorizer 
test cases. He might be on vacaction now, but it would be interesting to 
get his results.

As the design of the vectorizer is a very hot topic, I was wondering if 
there will be a BoF session on the LLVM conference? Nadav, you have not 
proposed one by accident?

Tobi