This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: A case exposing code sink issue
- From: "Jiangning Liu" <jiangning dot liu at arm dot com>
- To: "'Michael Matz'" <matz at suse dot de>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 28 Nov 2011 10:44:55 +0800
- Subject: RE: A case exposing code sink issue
- References: <000001ccaa5e$49413640$dbc3a2c0$@liu@arm.com> <000301ccaa76$43236e00$c96a4a00$@liu@arm.com> <000401ccaa7d$f7bf6010$e73e2030$@liu@arm.com> <Pine.LNX.4.64.1111251524280.26507@wotan.suse.de>
> -----Original Message-----
> From: Michael Matz [mailto:matz@suse.de]
> Sent: Friday, November 25, 2011 11:23 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
> Hi,
>
> On Thu, 24 Nov 2011, Jiangning Liu wrote:
>
> > One more question...
> >
> > Can " i = i.6_18;" be sinked out of loop, because it doesn't have
> memory
> > dependence with others?
>
> With current trunk the stores to i, a_p, b_p and k are sunken after the
> loop. (There are no aliasing problems because the decls can't
> conflict).
>
> What isn't sunken is the calculation of the &a[D.2248_7] expression.
> First, the number of iterations of the inner loop can't be determined
> by
> current code (replacing i+=k with e.g. i++ could be handled for
> instance).
Hi Michael,
Do you know what the essential problem is in the case of loop iteration
uncertainty? I thought it was still an aliasing problem.
Thanks,
-Jiangning
> Then this code could be handled by final value replacement, but isn't
> because interpret_rhs_expr doesn't deal with ADDR_EXPR of ARRAY_REFs.
>
>
> Ciao,
> Michael.