A case exposing code sink issue

[Michael Matz]

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.

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