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: Michael Matz <matz at suse dot de>
- To: Jiangning Liu <jiangning dot liu at arm dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 25 Nov 2011 16:23:24 +0100 (CET)
- 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>
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).
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.