Sort of. It's for when you know beyond a shadow of a doubt that something
should work best inline. But I generate code, I don't write it. Maybe if
I read the output code I'd be able to make sensible decisions about what to
inline and what not to, but I certainly don't and the people who use my code
generator don't. I do emit a few "inlines" but I generally would have
to duplicate gcc's calculations in order to tell it to inline when it
should anyway have inlined just by virtue of being asked to optimize.
I'm not going to do that.
Let's look at what gcc says:
By declaring a function `inline', you can direct GNU CC to integrate
that function's code into the code for its callers. This makes
execution faster by eliminating the function-call overhead; in
addition, if any of the actual argument values are constant, their known
values may permit simplifications at compile time ....
...
You can also make all "simple enough" functions inline with the
option `-finline-functions'. Note that certain usages in a function
definition can make it unsuitable for inline substitution
When is a function simple enough? Any function ought to be inlineable
in theory, but doing so may slow things down by creating resource
pressures. Only the compiler can know if it's a good thing or not, and it
knows because it knows the pressures it's under. So it's in a good
place to decide whether inlining looks good.
Sometimes I can make better guesstimates than the compiler. But every
one of my guesses can be invalidated by a perfectly correct compiler
strategy. And sometimes inlining everything will blow up the compiler
(when it optimizes).
I am willing to bet that inlining functions that just call another
function and pass back its return value should be inlined. But what
else? I leave it to the compiler.
> Linus isn't saying the compiler should ignore the inline keyword, far
> from it, he just doesn't want the compiler to inline things we don't
> tell it to.
> (Linus, please correct me if I am misrepresenting what you said)
That would be unfortunate. It would require me to know as much as the
compiler in order to optimize code to the same level as the compiler
could. But yes, Linus may be saying that!
> memory refs off of a struct. that is what I think inline's are great
> for. And in these cases, I do get huge speed-ups (inlining operator []
> on an array class for example)
I agree. That should be an obvious case. I quote again:
GNU CC automatically inlines member functions defined within the
class body of C++ programs even if they are not explicitly declared
`inline'.
(hic. I think I just read that stuff that occurs inside the same
brackets as the prototypes gets inlined automatically, whether or not
it's a good idea! I must be drunk).
> so please don't tell me all compiler's get it right). Now I am using
They don't. I only want them to do it righter than not doing it at all.
I can't guarrantee to make better guesses than the compiler in general.
>
> Regards,
> Steve Roberts
>
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/