lkml.org 
[lkml]   [2004]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Is extern inline -> static inline OK?
From
Date
Tim Bird <tim.bird@am.sony.com> writes:

> H. Peter Anvin wrote:
>> Followup to: <4112D32B.4060900@am.sony.com>
>> By author: Tim Bird <tim.bird@am.sony.com>
>> In newsgroup: linux.dev.kernel
>>
>>>Pardon my ignorance...
>>>
>>>Under what conditions is it NOT OK to convert "extern inline"
>>>to "static inline"?
>>>
>> When the code is broken if it doesn't inline.
>
> Thanks!
>
> From what I have read, for either 'extern inline' or 'static inline'
> the compiler is free to not inline the code. Is this wrong?

Yes, it's wrong in current Linux 2.6. It currently defines inline to
inline __attribute__((always_inline))

> It is my understanding that...
> In the 'static inline' case the compiler may create a function in the
> local compilation unit. But in the 'extern inline' case an extern
> non-inline function must exist. If the compiler decides not to inline
> the function, and a non-inline function does not exist, you get a linker
> error. Are you saying that, therefore, 'extern inline' functions are
> used (without definition of extern non-inline functions to back them)
> in order to guarantee that NO non-inline version of the function exists?

Exactly.

Originally it was used this way, but then the inlining algorithms got
completely broken to not explode compile times on broken C++ template
horrors, and in order to still compile the kernel most uses of extern
inline were converted to static inline.

Drawback is that you suddenly got a lot of binary bloat
(e.g. at some point gcc decided to not inline anymore
the constant evaluation code in copy_{to,from}_user,
which caused incredibly code bloat).

That is when the #define inline __attribute__((always_inline)) was
added.

> Or are you saying that the non-inline version of the function may
> be written differently than the inline version?

That was the original intention I think, but Linux always has used
it for the first interpretation.

It's pretty obsolete now, modern gcc has __attribute__((always_inline)),
which is a better way to do this. You get a compiler error when
the function cannot inlined. It also has a __attribute__((noinline))
for the opposite case.

Hope this helps,

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.025 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site