Re: [tree-ssa] Disastrous simplification of large switch stmt

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Op ma 23-09-2002, om 17:14 schreef Diego Novillo:
> On Mon, 2002-09-23 at 05:10, Steven Bosscher wrote:
> 
> > Look at the incredibly large number of temporaries we need to simpify
> > this function. If you compare his with the original make_node(), you can
> > see something needs to be fixed here.
> > 
--- 8< ---
> It is not the job of the simplifier to do dataflow analysis to figure
> out if something is obviously dead or redundant.  It can only deal with
> things that need no dataflow analysis to figure out.

Well, obviously that's true. But in this case, I don't see any temporary
that is "obviously dead". Every one of those temporaries is used.

> 
> The only thing that the simplifier must do right is output the program
> in SIMPLE form.  Let the other passes deal with the lint produced by the
> simplifier.
> 
> 
> > (Perhaps we should put each case in the switch statement in a separate
> > binding level before simplifying...)
> > 
> Why?

There's a whole bunch of code like this for tree checks and fancy_abort
(15, to be exact):

                T.134 = "../../gcc/gcc/tree.c";
                T.135 = (const char *)T.134;
                T.136 = "make_node";
                T.137 = (const char *)T.136;
                tree_class_check_failed (__t, 116, T.135, 317, T.137);

For 15 identical cases in the function body, we create 60 temporaries at
the entry of the function. And this is only a relatively small switch
statement.

So we can do worse? Yes, we can! Make a .simple dump for:
- c-prety-print.c and enjoy 2740 (!) lines of 4-byte temporary
  variables in dump_c_node(). And that function is recursive...
- c-parse.c, and PgDn your way past 3129 number of temporaries
  in yy_parse().

What does this do with the stack?

(OK, you wouln't compile a release GCC with tree checking enabled, but 
there's Real World code like this, like in c-parse.c)

Also, aren't those temporaries supposed to have *local* scope if
possible, not the entire function? I admit I don't know that much about
GCC internals or optimization passes, but I'd expect that it would help
the optimizers if they know which variables are in scope and which are
not.
Eg., since most of these temporaries are pointers, what happens with
alias analysis if all of a sudden it has to deal with >2500 pointers
with function scope and a prety big function body?

(BTW: Did you notice that all the files with very large switch stms
(such as c-parse.c, fold-const.c, insn-recog.c, c-prety-print.c) are
also the files that take by far the most time to compile?)

Greetz
Steven