This is the mail archive of the
mailing list for the GCC project.
Re: PRE (sometimes) confuses ivopts/scev?
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>, gcc at gcc dot gnu dot org
- Date: Mon, 24 Jan 2005 19:54:42 -0500 (EST)
- Subject: Re: PRE (sometimes) confuses ivopts/scev?
- References: <200501250051.j0P0pT3O014791@53v30g15.boeblingen.de.ibm.com>
On Tue, 25 Jan 2005, Ulrich Weigand wrote:
Daniel Berlin wrote:
Unfortunately your patch doesn't change this because the variables
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
1. Edge incoming to loop doesn't change in the loop
Well, but "doesn't change in the loop" is quite something else
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
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,
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.