[LLVMdev] Vectorization of pointer PHI nodes

[Renato Golin]

On 14 October 2013 17:44, Nadav Rotem <nrotem at apple.com> wrote:

> Thanks for working on this.  As you said, we don't support pointer
> reductions.  Handling pointer reductions should be straightforward. You can
> copy the logic for handling RK_IntegerAdd and create a new enum entry for
> RK_PointerAdd.


Hi Nadav,

Thanks for the pointers, it's good to see that I wasn't too far away in the
wrong direction. ;)


You will need to detect the relevant patterns (GEP probably) and implement
> the cost model and vectorization parts.


There are at least two patterns that I wish to implement: multiple pointers
(previous example) and single pointer, like this:

for () {
  a = *read;
  ...
  *write = a;
}

They'll end up as the same type of vectorization, but the former only works
if the operations on all inputs are identical (which is my case) and will
most likely leave empty lanes in the vectors. But the second is a
traditional vectorization (after loop unrolling) where, by definition, the
operations are the same.

So, because I can have the multiple case, I'll have to check throughout all
operations on all lanes to make sure they're identical, and that might put
some stress on the vectorizer...


You will need to generate vector-geps that represent the pointer increment.
> Vector-GEPs are rare and this may trigger bugs in other parts of the
> compiler (Vector GEPs usually live between the vectorizer, which is a very
> late pass, until SelectionDAG builder). I wonder if this pattern is common.


I'll pay special attention to them, and will blame you whenever I find a
bug. ;)


Usually before I add new features to the vectorizer I write code that does
> an “fprintf” into a file every time I detect the pattern that I want to
> optimize.  Next, I run the LLVM test suite and look at the C files that
> triggered the patterns. This helps in estimating the profitability of the
> optimization and also to find additional interesting cases.
>

That is an interesting instrumentation, I'll do that.

Thanks!
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131014/f3d3682d/attachment.html>