Is extern inline -> static inline OK?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Tim Bird
Quoted 9 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Tim Bird <[email protected]> In newsgroup: linux.dev.kernelQuoted 5 lines
Pardon my ignorance...
Under what conditions is it NOT OK to convert "extern inline" to "static inline"?
Quoted 6 lines
Quoted 1 line
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))
Quoted 8 lines
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.
Quoted 2 lines
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
Quoted 8 lines · Andi Kleen
Quoted 3 lines · Tim Bird
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))
...
To be more exact:
It's defined this way in both 2.4 and 2.6, but only for gcc >= 3.1 (which support __attribute__((always_inline)) ).
Quoted 3 lines
Hope this helps,
-Andi
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed