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