On 7/13/05, Steven Bosscher <[EMAIL PROTECTED]> 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.
optimize_size
Description: Binary data
