Code Bloat g++

Mike Stump mrs@windriver.com
Fri Feb 18 20:06:00 GMT 2000


> Date: Sat, 19 Feb 2000 03:11:04 +0100 (CET)
> From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>

> Actually four times as many lexical blocks as lines of preprocessed
> code, if we remove empty lines, #-lines and typedefs:

> If you, or anyone else, is interested in preprocessed source, I'll be
> happy to provide that (< 100kB as .ii.gz).

> Ah, now that sounds interesting! How many beers do we have to offer
> you, Mike, to see a patch? :-)

:-)

If someone else would categorize them into cases, sort them based upon
the number of blocks per case for the sample code, and show us a
single simple example of each case it would go a long way towards
fixing it.

Also, one might check out kept_level_p and see _why_ the blocks are
staying around (if it is responsible for them).  I can see how they
cascade (once you have a subblock, you are doomed to have all
intermediate blocks), that seems wrong (non-optimal).  Also, adjoining
blocks can be collapsed ({{{{ }}}} is the same as { }).

Blocks are created by expand_fixup, this might be the source of them.
I'd be nice to know how many of the blocks you see are due to them?

Also, various expand_start_bindings call site with flags&2 == 2 I
think will always create these things.  SCOPE_NULLIFIED_P == 1 on
SCOPE_STMT will do it as well.  I wonder if
expand_eh_region_start_for_decl needs to call expand_start_bindings
with 2?  expand_expr:{BIND_EXPR,CLEANUP_POINT_EXPR,TRY_FINALLY_EXPR},
expand_start_target_temps also do this, and I wonder about them also.
Could be a much copied leftover from 1991 and before.

Once could try and punch them all down to 0 and see if things work
flawlessly (g++ testsuite, plus big C++ application with and without
-g).  In fact this might be easier than collecting information as I
suggested above.  If wiping the 2 to a 0 fixes things without apparent
damage, I think I am in favor of putting that in.

Let us know what you find.


More information about the Gcc mailing list