Re: Function body size estimates

[Jan Hubicka <jh at suse dot cz>]

> 
> Hi,
> 
> I played a bit with the function body size estimates.  I used this patch to
> get the total size in insns for a large sample of functions in libstdc++-v3:
> 
>      
> So this gives me the function body size _after_ all inlining is done.
> tree-inline keeps DECL_NUM_STMTS up-to-date after inlining, so this is OK.
> AFAIK, no other optimizations happen between the tree-inliner and expand.
> Do you think these measurements make sense? If so I'll post something like
> this on the gcc list as well.
> 
> Attached is the output.  I have already picked my favorites:
> 
> __base_ctor guessed: 3120; insns: 99; notes: 218
> __comp_ctor guessed: 3120; insns: 99; notes: 218
> seekoff guessed: 2300; insns: 194; notes: 331
> seekpos guessed: 1690; insns: 116; notes: 242
> 
> Opinion?

Hmm, this is ineed conviencing :)
Since it is hard to do it worse than we do right now, I got into
busyness of making wrong sollution to the wrong problem and implemented
simple function that walks the tree without duplicates and counts expressions,
statements and knows about few special cases (no-op
statements/expressions, expensive statements/expressions like divide).

I am just testing it and it seems to work much better.  Nice about it is
that it responds nicely to the memory requirements to the compiler and
at least it results in faster copmiles as it can not be fooled to inline
very expensive function.

It is currently hooked into my unit-at-a-time scheme, but I will try to
replace DECL_NUM_STMTS by it and lets see how dificult it is to re-tune
current heuristics and my new one into this attrubute.
Does this seem to make sense?

Honza
> 
> Gr.
> Steven
> 
>