[PATCH] Vectorizing Global Structures - Take 2

[Arnold Schwaighofer]

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

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.



Thanks for your input,
Arnold