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?
Cheers,
Roberto
