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

[Daniel Berlin <dberlin at dberlin dot org>]

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.

I'm thinking this problem occurs because bb 20 is one statement long, 
so that the container it picked wasn't just the end of bb 20, it was 
also the *head* of bb 20.  If there was another statement, we'd have 
another compound_expr that would be the container, and we wouldn't have 
screwed anything up.

That guess said, I'm honestly not sure what should have happened here, 
since it just makes my brain explode to try to follow and explain 
what's going on. :)

Attachment: bug.c
Description: Text document