This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Preserving alias analysis information
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Roberto COSTA <roberto dot costa at st dot com>
- Cc: GCC mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 20 Feb 2007 00:07:33 +0100
- Subject: Re: Preserving alias analysis information
- References: <45D9BB19.9000604@st.com>
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