This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, 2002-09-23 at 12:24, Steven Bosscher wrote:

> > 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.
> 
Ah, OK.  We are in agreement then.  Yes, the simplifier generates rather
awful code.  Now that it's working (most of the time), we need to think
what optimizations to implement to clean all that gunk up.

One possibility is for the RTL expander not create stack slots for all
the artificial temporaries.


> 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.
> 
Ah, now I see what you're getting at.  In this case copy propagation
should help.  Notice that if you had made different scopes for all these
variables, you would've made copy-propagation harder because all the
redundant copies are now in non-intersecting scopes.


> 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?
> 
1.4Gb of core used by cc1.  17 CPU minutes to compile one of the insn-*
files with full may-alias information enabled.  But scoping wouldn't
have helped you in this case, we already know that artificial variables
cannot be aliased by program pointers.  And most of the may-aliases are
between top-level variables and pointers created by the TREE_* macros.
We can aggregate may-alias information in various ways (I'm working on
one of them now).
 

> (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?)
> 
Welcome to my world.  Share my pain  :)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]