On 7/13/05, Steven Bosscher <stevenb@suse.de> wrote:
> On Wednesday 13 July 2005 04:29, Josh Conner wrote:
> > > Finally, you've apparently used grep to find all the places where
> > > PARAM_MAX_INLINE_INSNS_SINGLE and its friends are used, but you hve
> > > missed the ones in opts.c and maybe elsewhere.
> >
> > Hmmm - I looked for all of the places where estimate_num_insns was
> > called.  I still don't see anything in opts.c -- can you give me a
> > little more of a hint?
> 
> From opts.c:decode_options()
> 
>   if (optimize_size)
>     {
>       /* Inlining of very small functions usually reduces total size.  */
>       set_param_value ("max-inline-insns-single", 5);
>       set_param_value ("max-inline-insns-auto", 5);
>       flag_inline_functions = 1;
> 
>       (...)
>     }
> 
> You didn't update those two.

Note that I'd rather change these to set the inline-unit-growth to zero
for -Os.  I even have a patch for this laying around.  Though it will
no longer apply :)

Also rather than making estimate_num_insns target dependent, we should
maybe conditionalize the results on whether we are optimizing for size
(which is what I think the current metric should do) or for speed (where we
really should drop the costs for all the real multiplication/division stuff).

An important invariant is, that we do not grow the size of a forwarder
function like int foo(int i) { return i; } int bar(int i) { return
foo(i); } whether
foo is inlined or not.  I don't remember if I added testcases to verify this
in the last round of adjustments.

Finally, CSiBE is your friend for all size checks, certain C++ testcases
from PRs, like Geralds testcase, for compile-time (and runtime, if available).
And of course compiling gcc itself.  Remember, it's hard work to get overall
improvements, especially if you consider embedded targets (I didn't ;)).

Richard.