> -----Original Message----- > From: Michael Matz [mailto:m...@suse.de] > Sent: Monday, November 28, 2011 9:07 PM > To: Jiangning Liu > Cc: gcc@gcc.gnu.org > Subject: RE: A case exposing code sink issue > > Hi, > > On Mon, 28 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? > > Yes, the number of iterations of the i loop simply is too difficult for > our loop iteration calculator to comprehend: > > for (i=k; i<500; i+=k) > > iterates for roundup((500-k)/k) time. In particular if the step is > non-constant our nr-of-iteration calculator gives up.
So do you think this can be improved somewhere? For this case, looking at the result in middle end, "a_p.2_8 = &a[D.2248_7];" should be able to sunken out of loop. That way the computation of &a[D.2248_7] would be saved in loop, although the consequence is the liverange of D.2248_7 is longer and it needs to live out of loop. But anyway the register pressure would be decreased within the loop, and we would less possibly have spill/fill code. This is what I want. I think we can simply use loop induction variable analysis to solve this problem. Do you think so? Thanks, -Jiangning > > > I thought it was still an aliasing problem. > > No. All accesses are resolved to final objects (i.e. no pointers), and > hence can be trivially disambiguated. > > > Ciao, > Michael.