> -----Original Message----- > From: Michael Matz [mailto:m...@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.
