[PATCH] Vectorizing Global Structures - Take 2

Renato Golin renato.golin at linaro.org
Tue Feb 12 10:25:09 PST 2013


Hi Arnold,

Thanks for the review!


On 12 February 2013 17:43, Arnold Schwaighofer <aschwaighofer at apple.com>wrote:

> The existing Analysis tests for "overlap" between memory regions
> (underlying pointers). As such, it can ignore the access pattern and can
> operate using just the pointer and the underlying object.
>

Hum, ok, that should simplify a lot the code, then. Though, I could only
find the getLocation() with StoreInst, LoadInst, VAArgInst, not generic
values.


We will have to ask "Do the future vectorized accesses overlap?" Something
> like:
>
> AA->alias((&A[i+1], MaxVF*4), (&A[i], MaxVF*4)).
>

I know, there was a comment on the previous patch to that effect. I
couldn't find an AA method to inspect memory considering strides. It might
be possible to examine the edges, but it'd be more efficient to do that
inside AA. I assume this is done elsewhere, maybe I could re-use the same
idea.


Also, for the writes you use the underlying object to look up a value in
> the ReadWrites multi-map that is populated with "getPointerOperand()" which
> is not necessarily the underlying object.
>

That is how the vector was populated, I just stored the instruction
alongside it to retrieve later on. From what you said above, it might not
be necessary (but I'd have to have a way to check aliasing on the
underlying objects).

I spent some time looking at that part of the code and I'm still in doubt
as to what that possible regions can the underlying object point to, or if
the underlying object is always accessible via the pointer operand.

The code seems marginally ok, since all the other vectorization cases are
still working and the new global alias also works, but that doesn't say
much...

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130212/9acc99f4/attachment.html>


More information about the llvm-commits mailing list