RE: A case exposing code sink issue

["Jiangning Liu" <jiangning dot liu at arm dot com>]

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