On 2/19/07, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello,
I've got a question for experts of alias analysis in GCC.

In the CLI back-end of GCC, there is a CLI-specific pass responsible of
some modifications on GIMPLE that simplify the emission of CIL bytecode
(see http://gcc.gnu.org/projects/cli.html#internals for more details).
One of such modifications makes sure that all ARRAY_REF nodes have zero
indexes. ARRAY_REFs with non-zero indexes are transformed into
zero-index equivalent plus some pointer arithmetics.
After noticing a failure of the CLI back-end in gcc.dg/struct-alias-1.c
test from the testsuite, I'm concerned that doing so may decrease the
effectiveness of GCC alias analysis.

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?

No. Sadly, this is done because we allow both positive and negative
offseting of structure fields to get to other structure fields.  Thus,
we can't prove that s.a and s.x do not alias here.

You could invent an attribute for field accesses that specify that
even though they look variable, they never stray outside their own
field.


Cheers,
Roberto

Reply via email to