Attacking quadratic behaviors associated with SWITCH_EXPR
Daniel Berlin
dberlin@dberlin.org
Mon Oct 25 20:12:00 GMT 2004
On Mon, 25 Oct 2004, Kazu Hirata wrote:
> Hi Zack,
>
>> I concur. In fact, I'd go farther, and suggest that we ought to be
>> working with edges directly, everywhere we are currently working with
>> labels, except in the parsers.
>
> Yes. I am thinking about starting with SWITCH_EXPR. After that's
> complete, we can probably remove GOTO_EXPR from COND_EXPR during the
> lifetime of CFG.
If this means i can simply redirect edges instead of frobbing around with
labels, edges, and little bits of fairy dust, go for it.
Let me give you an eaxmple of real code today, and if you could, can you
tell me what will still be required?
then_label = build1 (GOTO_EXPR, void_type_node, tree_block_label
(latchbb));
else_label = build1 (GOTO_EXPR, void_type_node, tree_block_label
(olddest));
cond_stmt = build (COND_EXPR, void_type_node,
build (NE_EXPR, boolean_type_node,
integer_one_node,
integer_zero_node),
then_label, else_label);
bsi = bsi_start (bodybb);
bsi_insert_after (&bsi, cond_stmt, BSI_NEW_STMT);
make_edge (bodybb, olddest, EDGE_FALSE_VALUE);
make_edge (bodybb, latchbb, EDGE_TRUE_VALUE);
I'm guessing all i'll need is something like
thenedge = make_edge (bodybb, latchbb, EDGE_TRUE_VALUE)
elseedge = make_edge (bodybb, olddest, EDGE_FALSE_VALUE)
cond_stmt = build (COND_EXPR, void_type_node,
build (NE_EXPR, boolean_type_node,
integer_one_node,
integer_zero_node),
thenedge, elseedge);
bsi = bsi_start (bodybb);
bsi_insert_after (&bsi, cond_stmt, BSI_NEW_STMT);
Is that about right?
>
>> One might even speculate about the feasibility of constructing the
>> cfg inside the parser...
>
> Wow, I haven't thought about that far, yet. :-)
>
> Kazu Hirata
>
More information about the Gcc
mailing list