[PATCH] Vectorizing Global Structures - Take 2

[Daniel Berlin]

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 A {
>>
>> struct S {
>>   union {
>>    int a;
>>    int b;
>>   }
>>   int c;
>> } s;
>>
>> struct T {
>>   int d;
>>   union {
>>    int e;
>>    int f;
>>   }
>> } t;
>>
>> };
>>
>> union A foo;
>>
>> foo.s.a = ...
>> foo.s.b = ...
>> foo.s.c = ...
>> foo.t.d = ...
>> foo.t.e = ...
>> foo.t.f = ...
>>
>>
>> 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.

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

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.

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

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


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