Preserving alias analysis information

Zdenek Dvorak rakdver@atrey.karlin.mff.cuni.cz
Mon Feb 19 23:07:00 GMT 2007


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



More information about the Gcc mailing list