Re: PRE lossage

[Daniel Berlin <dberlin at dberlin dot org>]

On Oct 28, 2003,
> Note the bogus PHI:
>
>  # block 3.  pred: 7 6 2.  succ: 5 4.
>  #   pretmp.5_14 = PHI <pretmp.5_15(6), T.1_7(1), T.1_7(2)>;
>
> The PHI references T.1_7 from block #1, but block #1 is not a 
> predecessor of
> block #3.  Furthermore the PHI does not have an argument for block #7.

This type of lossage only happens on critical edge splits where 2 
blocks are created.

What happens is that our insertion requires splitting a critical edge 
to start with, and then the actual insertion code 
(find_insert_location) calls handle_switch_fallthru, which recursively 
calls bsi_insert_on_edge_immediate, which splits another critical edge 
and creates a new block.

Thus, we actually end up creating two blocks, but we only know about 
one, and it's the wrong one.
So we update the edge on the EPHI to the wrong edge, and end up with a 
PHI with a bogus argument.

> The EPHI looks like:
> #1  0x080d8d5b in code_motion (ei=0xbf1de480) at 
> /speedy/export/virgin-tree-ssa
> /gcc/tree-ssa-pre.c:2779
> 2779                  add_phi_arg (&newtemp, rdef, EPHI_ARG_EDGE (use, 
> i));
> (gdb) p debug_generic_stmt (use)
>  EPHI (code0_5 - 7) [ class:1 downsafe stops bb:3] <
>    edge 6->3 [  ]  defined by: EUSE (code0_5 - 7) [class:3 phiop:0 
> bb:0 ]
>    edge 1->7 [  real use stops ]  defined by: EUSE (code0_5 - 7) 
> [class:0
> phiop:0 bb:1 ]
>    edge 2->3 [  real use stops ]  defined by: EUSE (code0_5 - 7) 
> [class:0
> phiop:0 bb:1 ] >
>
>
> Looks like the EPHI is bogus to me.

We try to update the EPHI edge to account for the split (so that we 
have the right edges in the created phi), but if the split creates more 
than one block, we don't do it right.

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.



> jeff