Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Brent Fulgham <[EMAIL PROTECTED]> writes:
> >The 'inline' keyword is just a hint to the compiler. If optimization
> >is turned off, no inlining is done. If optimization is on, the
> >compiler may or may not decide to inline. Performance on different
> >compilers will vary.
> >
> >To repeat: Even if I say "inline" on everything, the compiler is
> >free to disregard that if its optimization routines decide not to.
> >(Also, if I fail to say "inline" on something, the compiler may
> >decide to inline if optimization is active).
> >
> >So aren't we all saying the same thing?
>
> I don't think so - it is a question which way we code the source:
>
> A. Use 'inline' every where and trust compiler not to do what we told it
> if it knows better.
> B. No inline hints in the source and trust the compiler to be able to
> do the right thing when prodded with -O9 or whatever.
> C. Make "informed" guesses at to which calls should be inlined.
>
> My view is that (B) is the way to go, aiming for (C) eventually, because
> (A) gives worst-case cache purging.
There doesn't have to be an 'eventually'. We can have (C) now.
Having both forms available (i.e., the suggestion that started this
thread) lets us 'help' the compiler, which, as Brent points out, is
free to ignore our hint under normal optimization flags.
Moving from a first-guess (C) to an optimal (C) (where we make
reasonable hints all the time, no doubt with the aid of some Configure
tests or machine-dependent conditionals) can be an ongoing pursuit.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
