This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: A case exposing code sink issue



> -----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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]