Hello,
> For instance, let's consider the following struct definition (taken from
> gcc.dg/struct-alias-1.c):
>
> struct S {
> int a[3];
> int x;
> };
>
> This is the original code in GIMPLE pseudo-C dump representation:
>
> s.x = 0;
> i.0 = i;
> s.a[i.0] = 1;
> D.1416 = s.x;
> if (D.1416 != 0) goto <L0>; else goto <L1>;
> <L0>:;
> link_error ();
>
> This is the code after the CLI-specific array simplification:
>
> s.x = 0;
> i.0 = i;
> cilsimp.1 = &s.a[0];
> D.1423 = i.0 * 4;
> D.1424 = D.1423 + cilsimp.1;
> *D.1424 = 1;
> D.1416 = s.x;
> if (D.1416 != 0) goto <L0>; else goto <L1>;
> <L0>:;
> link_error ();
>
> In the original code, GCC alias analysis understands that accesses to
> s.x and s.a do not alias; therefore, it understands that the "then"
> condition of the if statement is never taken.
> In the modified code, the alias analysis conclude that access to s.x and
> pointer D.1424 may alias.
> My question is: is this unavoidable because of the memory access pattern
> in the modified code, or was there additional information the
> transformation pass could have attached to D.1424 (or to something else)
> that would have have excluded such a memory alias?
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs the same
as before the transformation (unless that got broken in last few months,
which unfortunately is pretty likely).
Zdenek
