[PATCH] Vectorizing Global Structures - Take 2

[Renato Golin]

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

> The existing implementation already relies on runtime checks (it has to
> make sure that an unknown object and a known object do not overlap). Yes,
> AA will conservatively return MayAlias/PartialAlias if it does not know two
> objects. You just have to make sure that you actually query it with that
> unknown object.
>

I was expecting this, and I'm planning to be extra conservative to begin
with. So, for now, MayAlias and PartialAlias are reasons to stop trying.
Once we can get the code to understand basic independent objects inside a
structure, we can specialize for the other cases.


Say you have three access in your program: one has underlying object A, one
> has underlying object B, and one has an unknown underlying object U. If you
> just rely on AA, you have to query both pairs ((Access A), (Access O)) and
> ((Access B), (Access O)).
>

My current proposal does that if the unknown underlying object can be
retrieved from GetUnderlyingObjects(). If unknown means the array is empty,
than maybe we should add a special condition to bail, at least for now.


 alias((&S.a[99], 4xsizeof(int)), &S.b[0], 4xsizeof(int)) == partial alias
>>
>
> That's great! So I can rely on AA to do the hard work for me, just need to
> give it the correct Size.
>
> I think you read to quickly :). Partial alias is bad. You want NoAlias. I
> am warning that if we use alias analysis the way we have to we might not
> get the answer we would like to see.
>


I meant that I can bail on any slightly dangerous case for now, and add
special cases later on PartialAlias, if I know how to change the induction
range to make it not alias while vectorized.




> AA will analyze address computations (it looks at the existing IR which
> still has the scalar bounds):
>
> (&S.a[0.99], sizeof(int)*VF) and (&S.b[0], sizeof(int)*VF)
>
> and there is an overlap due to the increased access size.
>

Since this is still in the legalization phase, we can't have access (nor
create new) vector IR to make the alias analysis work correctly.

For instance the code:

for (k: 0..100) {
  S.a[100-k] = S.b[k] + 1;
}

Will be PartialAlias with the "pretend-vectorization-alias-analysis", while
you could vectorize by reversing S.b and changing the start of the
iteration.

But in cases like that, I'd rather add as a special case (possibly adding
more types of reduction), than trying to get it right with the first and
generic implementation.

I think I'll create a few examples that should and should not vectorize, so
I can have a clearer view of how to apply that model to code.

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