Attacking quadratic behaviors associated with SWITCH_EXPR

[Kazu Hirata]

Hi Andrew,

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

Some people were against the implicit GOTO_EXPR and the idea of making
CFG a part of IL.  See a long dicsussion starting from

http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00985.html

Yes, a different opcode may be nicer than putting NULL_TREE into the
last two fields of a COND_EXPR.

Anyway, updating goto labels just for the sake of updating them does
not make sense.  I believe they are needed only before CFG is created
and at expand time.

Kazu Hirata