[PATCH] Vectorizing Global Structures - Take 2

[Arnold Schwaighofer]

On Feb 16, 2013, at 8:52 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> On Sat, Feb 16, 2013 at 8:46 PM, Arnold Schwaighofer
> <aschwaighofer at apple.com> wrote:
>> 
>> On Feb 16, 2013, at 6:52 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>> union
>>> Unlike TBAA, this can all simply be tagged as a bunch of byte range
>>> accesses inside "foo". Then calculating aliasing is just a constant
>>> time intersection.
>>> If you want to talk about the type instead of the variable (IE tag
>>> these with union A.s.a, A.s.b,etc) for each independent type, you can
>>> calculate the possible separate byte ranges that could be accessed on
>>> a per-type basis.
>> 
>> If I understand you correctly, LLVM's BasicAA does something in principle similar to this. Except it does it on demand and not on a type basis.
> 
> This is a little different.
> BasicAA tries to calculate base + offset + stride using only the
> variables, it uses no source info to do this.

Yes. Similar in that it reasons at the address computation level (like your described approach).

> 
>> For a two foo accesses above it decomposes the address computation into know base offset + scaled symbolic offsets and then reasons about overlap.
>> Unfortunately, it fails in the two array fields (struct {int a[2];int b[2]} x,y; x.a[i]; x.b[y];) example. But it (or a similar analysis) could be helped by something like field tags that convey more language guarantees.
> 
> Yes.
> 
>> 
>> It is different to the described approach above (as I understand it) in that it is not (source language) type based but purely address
>> computation (llvm ir type) based.
> 

I was pointing out the difference between what BasicAA does and your described approach.

Your approach:

  Source language  type -> address based info in LLVM IR -> analysis

BasicAA:

  [[Source language -> (we loose information) -> ]] LLVM IR -> address based info -> analysis

I think we are in agreement.
 
> Not quite.I'm saying you simply convert the source language type based
> info into address based info, since that is what you are really
> checking anyway.  IE i'm suggesting lowering it further than you are
> before putting it into the metadata.
> 

Yes, I understood this. I called it source language type based because it is this information that is used to encode address computation information.

> You aren't really encoding anything different into your TBAA tree
> version (that I can see), you are just naming things differently.
> 

Yes.

> Maybe you could give a case where you will produce a disambiguation
> that knowing base, offset, stride + existing TBAA will not?

I can't, I was not disagreeing with you.

>> Thanks for your input,
>> Arnold
>>