A case exposing code sink issue
Jiangning Liu
jiangning.liu@arm.com
Mon Nov 28 17:49:00 GMT 2011
> -----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.
More information about the Gcc
mailing list