Re: PRE (sometimes) confuses ivopts/scev?

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 25 Jan 2005, Ulrich Weigand wrote:

> Daniel Berlin wrote:
>
> > > Unfortunately your patch doesn't change this because the variables
> > > fail the
> > >
> > >      if (firstinsideloop ^ secondinsideloop
> > >          && is_gimple_min_invariant (avail[outsideloopblock->index])
> > >          && !is_gimple_min_invariant (avail[insideloopblock->index]))
> > >
> > > test -- the outsideloop value is not invariant (because it varies
> > > with the next outer loop).
> >
> > > Why is this test required in the first place?
> >
> > Because induction variables should be 2 argument phi nodes with the
> > following property:
> >
> > 1. Edge incoming to loop doesn't change in the loop
>
> Well, but "doesn't change in the loop" is quite something else
> than is_gimple_min_invariant!

Hence why i said you could do better :)
> Maybe I'm missing something here, but how *could* the *incoming*
> value change in the loop?  Its definition is outside the loop ...

I was thinking of very weird control flow when i wrote it.  Maybe it isn't 
actually possible.
This was a patch that was posted for 4.0 at a point where nobody had 
serious regressions without it.
So i made it as conservative as possible, and told myself i'd revisit 
that piece of code for 4.1.
Now that i've learned it's actually causing someone serious performance 
problems, i'm working on fixing it.



> >   If I remove it,
> >
> > Remove what?
>
> The two is_gimple_min_invariant checks.
>
> > If you remove the test and replace it with 1, it'll never PRE anything.
>
> I did leave in the
>   if (firstinsideloop ^ secondinsideloop)

This is pretty much what i'm testing now.