Re: kernel-2.2.1-undefined references.

[mrs@wrs.com (Mike Stump)]

> Date: Mon, 8 Feb 1999 12:15:40 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>

> I'm not trying to be unreasonable. I'm just saying that if there is
> a function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the
> programmer.

Let me provide a counterpoint.  In C++, it is common to have
templates.  In templates, it is common to have lots of small,
sometimes, really small functions.  Sometimes, programmers put
`inline' on them.  The C++ standard says they `inline' by default on
those defined in the class body, this also is common.

Now, if you put all of that into a complex piece of software, you wind
up with cases where, the compiler wants to consume 10 terabytes of
swap space trying to fulfill the users desire to inline.  Yes, I am
not marking this up, it happens (see a user bug report from use a few
months ago for this exact case).  We have a choice, require they
change their source code (not an opnion, it looks quite nice already),
require they buy 10 terabytes of swap (only $216k, so why not?), don't
compile their code and tell them to go out and buy a better compiler,
or stop inlining just for C++ (I don't like random divergence), or
require they not put inline on things or define them in the class body
or violate the users expectations set from the standard for C++.

Which do you prefer?

I prefer to follow the standard where it says that inline is a hint,
and only a hint.  I have submitted patches to artificially limit the
size of functions that can be inlines to some random size that was
meant to be big enough, so that it would be faster in the typical case
(due to caching effects), than if there were no limit, and so that the
code would even compile.  The limit was something like 6400
instructions.  I tried to pick it so that if everything fit in the
cache, performance would still be within 1% or so of perfect.