[tree-ssa]: After edge insertion, two bb's share the same heda

[Daniel Berlin]

On Saturday, July 26, 2003, at 9:20 PM, Daniel Berlin wrote:

>
> On Saturday, July 26, 2003, at 5:08 PM, Daniel Berlin wrote:
>
>>>
>>>> Note that 345 was an empty block (but still had the same 
>>>> head_tree_p)
>>>> at the time 444 was created by bsi_insert_on_edge_immediate.
>>>>
>>>> The edge we insert on is also from 54->346 (346 is the successor 
>>>> block
>>>> of 345), so it looks like collateral damage that we chose the same
>>>> head_tree_p as block 345.
>>>>
>>> Soooo. What block is the switch stmt in?
>>> Whats block 345? I clearly need
>>> more context :-)
>>
>> Yeah, i'm working on minimizing a testcase for you.
>>
>> it occurs in combine.c from 176.gcc, in simplify_shift_const.
>> It's not a nice looking function, so i set my automatic test case 
>> minimizer on it an hour ago to see if we could come up with something 
>> smaller that still fails. It's slow, but it's working on it, and 
>> getting somewhere.
>> I've already halved the number of bb's in the failing functions.
>> :)
>
> Okay, i've gotten it down to 60 lines of code, 31 bb's (it was 4000 
> lines before, 543 bb's).
> I've attached the code.
>
> Breakpoint on bsi_insert_on_edge_immediate, hit run, and it's the 
> second bsi_insert_on_edge_immediate call (which is the first one that 
> creates a new bb).
>
> Look at the head_tree_p of basic_block 20, then, look at the 
> head_tree_p of the bb 30 it creates when the insertion is done.
>
> For simplicity, here's the relevant blocks, and where we are inserting.
>
> What happens is this:
>
> 1. We have a switch statement, like so:
> # BLOCK 9 (bug.c:37).  PRED: 8 7 6.  SUCC: 10 21.
>         #   code_2 = PHI <code_29(6), code_1(7), code_1(8)>;
>         #   .GLOBAL_VAR_5 = PHI <.GLOBAL_VAR_19(6), .GLOBAL_VAR_19(7), 
> .GLOBAL_VAR_4(8)>;
>         #   VUSE <.GLOBAL_VAR_5>;
>         T.12_30 = varop_17->code;
>         T.13_31 = (int)T.12_30;
>         switch (T.13_31)
> 	{
>
> 	  {
>
> ....
>     		# BLOCK 20 (bug.c:51).  PRED: 19 18.  SUCC: 21.
> 	<THIS BLOCK IS INSIDE THE BIND_EXPR_BODY OF THE SWITCH STATEMENT>
>               	goto <UL1070>;
>             	}
>           	};
>
>         # BLOCK 21.  PRED: 20 14 9.  SUCC: 23.
> 	<THIS BLOCK IS OUTSIDE OF IT, AFAICT>
>         <UL1070>:;;
>         goto <ULcf50>;
>       };
>
>
> We go to insert on the edge between block 9 and block 21
> It creates a new basic block to do this, bb 30.
> So it then goes to find the insert location for the statement.
> It then notices it's inserting into a switch statement, sees it's 
> inserting into the fallthru, and calls handle_switch_fallthru.
> Handle switch fallthru starts to do it's thing, eventually calls:
> 3820      tsi = tsi_last (&BIND_EXPR_BODY (SWITCH_BODY (sw_stmt)));
>
> The tsi it returns is a pointer to the head of basic block 20 (which 
> is the correct last thing in the bind_expr_body, AFAICT).
> At this point, we link the new case label after that statement (which 
> is a statement really in bb 20, still :P), so that bb 20 now looks 
> like:
> 51  goto <UL1070>;
> -1  default :
>
> We then try to append the container (which is the pointer to the head  
> of bb 20) to the new bb, which causes the two bb's to now share a 
> head.
>

On this note, if i comment out the first append, which appends the 
current container (IE line 3287 of tree-cfg.c, not line 3289) it seems 
to do the right thing, which is not screw up the old block, and 
simultaneously make the new block look okay.

But of course, i'm shooting in the dark here :)