This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PRE (sometimes) confuses ivopts/scev?

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]