Attacking quadratic behaviors associated with SWITCH_EXPR

Zdenek Dvorak
Mon Oct 25 21:18:00 GMT 2004


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

yes.  From what little I remember from the discussion, there were no
real arguments against the change, except for general dislike for any
change to IL (also my patch for it attempted to do too many things at

It would indeed be great to be able to expand statements directly to
cfg, and it would not be principially hard; the main problems are that
it would require a complete rewrite of gimplification (the current
system in that statements may get regimplified is too messy), and
something would have to be done about exception handling (the easiest
way probably would be to have cfg constructed in several pieces
corresponding to the eh constructs and perform the eh lowering in a
later pass as we do now).


More information about the Gcc mailing list