John Tobey <[EMAIL PROTECTED]> writes:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> (FWIW, it seems on many of the modern
>> processors that inlining code decreases your performance, so I think
>> deciding on stuff like that is rather premature)
>
>Is foo() compiled any differently in
>
> inline i_foo() { BLA; BLA; BLA; }
> foo() { i_foo(); }
>
>versus
>
> foo() { BLA; BLA; BLA; }
Maybe not for void functions with no args, tail-called and with
no prefix, but in more typically cases yes it can be different
the "function-ness" of i_foo applies constaints on where args
and "result" are which optimizer _may_ not be able to unravel.
Try it and see on your favourite architecture
gcc -S -O2 ...
and then diff the results.
>
>? I am not talking about forcing inlined functions down anyone's
>throat.
I believe that if function is defined before use "modern" C compilers
(e.g. gcc) can inline functions not declared such.
>Non-inline functions have their place in reducing code size
>and easing debugging. I just want an i_foo for every foo that callers
>will have the option of using.
Before we make any promises to do all that extra work can we
measure (for various architectures) the cost of a real call vs inline.
I want proof that inline makes X% difference.
If that proof is there and inline is a "significant win" then
we teach "PI" or whatever ends up being used instead of #define
to emit the above when "source" defines foo().
--
Nick Ing-Simmons
