Re: [PATCH]: Take loop depth into account when determining whichway to record the equality

[Daniel Berlin <dberlin at dberlin dot org>]

On Fri, 8 Oct 2004, Jeffrey A Law wrote:

> On Thu, 2004-10-07 at 08:45, Daniel Berlin wrote:
> > This patch changes DOM to fix the problem i mentioned yesterday, where it
> > was replacing loop invariant variables with loop variant ones, due to not
> > taking into account loop depth when deciding which way to record the
> > equality.   It now will look at the loop depths of the defining statements
> > of the name when trying to determine which way to record the equality, and
> > will choose the most loop-invariant name.
> > This should actually also improve our loop optimizations as well, since
> > they now have more invariants to work with.  I haven't SPEC'd the change,
> > however.
> > Bootstrapped and regtested on i686-pc-linux-gnu.
> >
> > Okay for mainline?
> >
> > 2004-10-07  Daniel Berlin  <dberlin@dberlin.org>
> >
> >  	* tree-ssa-dom.c (record_equality): Use loop depth to determine
> >  	which way to record the equality as well.
> >  	(loop_depth_of_name): New function.
> Is the loop depth information even available/kept-up-to-date during
> DOM?  That was the blocking issue with a similar change to avoid
> unprofitable reassociations a while ago.


It's available, but not necessarily up to date.
It's available because of the copy-headers pass calling the loop 
optimizer init.
Those blocks which are not up to date will simply have 0 as the loop 
depth, and we will do what we used to.

> > +}
> A couple empty lines would make this easier to read IMHO.  At the
> least you need one after the local variable declarations.

Okeydokey.
> And I think you wanted to use "<=" for the loop depth test itself in
> record_equality, not "<".
Okeydokey.

> But most importantly, I think you need to verify that we actually
> have loop information at this point (maybe we do and I'm just not
> aware of it).

We do, like i said. It just may not be up to date.
But it's still better than nothing.

> Jeff