[PATCH] Vectorizing Global Structures - Take 2

[Arnold Schwaighofer]

On Feb 14, 2013, at 12:34 PM, Renato Golin <renato.golin at linaro.org> wrote:

> 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.
> 

Okay. But understand that LLVM IR semantics does not give you much leeway in "understanding independent objects inside a structure". That is what you need TBAA for.

> 
> 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.
> 

Yes, I was just being verbose.

> 
>> 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.
> 

Yes. Scrap what I said I was over thinking the original example, we should be fine.

> 
>  
> 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/d7c3a05e/attachment.html>