Re: kernel-2.2.1-undefined references.

[Linus Torvalds <torvalds at transmeta dot com>]

On 8 Feb 1999, Matthias Urlichs wrote:
> > Alan Cox:
> > > 
> > > At this point egcs really needs to invent a new "common inline" of some
> > > sort. There are kernel cases where you need to force inlining and where
> > > you don't want duplicated code all over the place caused by compiler
> > > weaknesses.
> > 
> Why is that a weakness? If the compiler's optimizer says "this code runs
> faster when not inlined" (I can think of a couple of reasons why it would
> even be right doing that...), I'm not qualified to contradict it.

Umm.. You're thinking the wrong way.

If the programmer tells the compiler that the function should be inlined,
the compiler had better comply with that.  At least until the compiler
guys are certain that the compiler is smarter than the programmer, at
which point I will concede just about anything.

For Gods sake, the compiler is a _tool_, and if I tell the compiler that I
want something inlined, it had damn well better do it.

When I tell the compiler to generate code to compute PI, I _expect_ to get
the numbers of PI, not "e". With me so far?

When I tell the compiler to do an "extern inline", I _expect_ to get an
inline function. I may have special requirements that the compiler doesn't
know about (no stack frame, whatever), and the compiler had better not
second-guess what the programmer really meant. For example, I may have
fixup code that gets invoced on exceptions, and that fixup code may care
about where the error happened.

It certainly doesn't have to be "extern inline", but I do believe that we
need to have to have _some_ way of forcing inlining. Saying "the compiler
knows best" is just stupid - the compiler does NOT know best, because it
hasn't got a frigging clue about what the programmer really wants.

		Linus