Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >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.
May not be able because of what the Standard says, or because of
suboptimal optimization?
> >? 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.
GCC won't unless you go -O3 or above. This is why many people (me
included) stop at -O2 for most programs.
> >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.
I'm not going to prove that. A normal C function call involves
several instructions and a jump most likely across page boundaries.
If someone else wants to prove this, great. I just don't think it's
that much trouble. (mostly psychological - what will people think if
they see that all our code is in headers and all our C files are
autogenerated?)
I will, however, take your suggestion about comparing gcc -S output
for examples like mine above.
> 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().
Yes.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
