Attacking quadratic behaviors associated with SWITCH_EXPR

[Andrew MacLeod]

On Mon, 2004-10-25 at 13:26, Daniel Berlin wrote:
> On Mon, 25 Oct 2004, Kazu Hirata wrote:
> 
> > Hi Zack,

> > 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.
> 

>   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 seem to recall the issue when this was first proposed was back when
Zdenek brought implicit edges and flattened tree-ssa, was that we then
have a two state COND_EXPR, depending on whether the cfg is present or
not.  At the time the decision was that it was better to leave the
stmt's in the arms of the COND_EXPR, thus we ended up with the GOTO_EXPR
placeholders.  I also believe we thought we might want/need a different
opcode if the semantics were going to be changed.

However, I dont remember well past 4 about months ago :-). Many things
have changed since then, so is there still an issue here or is it gone
now? I cant think of anything off the top of my head, or perhaps I just
remember it poorly :-) It might also be that we were being cautiously
pessimistic about changing too much at once.

Andrew