This is the mail archive of the gcc@gcc.gnu.org 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: [tree-ssa]: After edge insertion, two bb's share the same heda



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



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