Re: PRE lossage

[Daniel Berlin <dberlin at dberlin dot org>]

On Oct 28, 2003, at 2:17 PM, law@redhat.com wrote:

> In message <64E3BF94-097A-11D8-A9DD-000A95AF1FAE@dberlin.org>, Daniel 
> Berlin wr
> ites:
> > I've been putting off these bugs until switch lowering happens, since
> > that should allow us to pre-split the critical edges without any
> > trouble, and once that happens, insertion shouldn't require creating
> > new blocks, ever, and the whole problem goes away.
> I would be very wary of pre-splitting critical edges.  In my 
> experience, it
> loses, badly.

Except that every compiler i know of does it (LLVM does it, Open64 does 
it, Intel's compiler does it, etc), and the papers for SSAPRE assume it 
specifically.
We also have to recompute a whole bunch of info if we split a critical 
edge (dominators, dominance frontiers, etc), and can't run ESSA 
minimization.
Thus, i'm not very wary of it, but only because i'm pretty sure the 
costs are less than the benefits.
But, we shall see.

>   Interestingly enough I was pre-splitting critical edges to
> help with PRE when I ran into the lame behavior.


Intriguing.  It might be a problem with switch insertion then.  I did 
verify that your testcase is one of the ones where we do a double 
critical edge split.  The first critical edge split doesn't need to 
update any phis, but the second (done by handle_switch_fallthru) does, 
and we don't know about it because we never get a hold of the second 
created block in our calling function, only the first.
> jeff