I notice that feature-removal-schedule.txt has CONFIG_FORCED_INLINING
scheduled to go away most of a year ago. My question is what replaces it:
Does #define inline __always_inline become the new standard and uses of
__always_inline be removed, or should all instances of "inline" either be
removed or replaced with __always_inline? (Or are there going to be two
keywords meaning exactly the same thing going forward?)
Rob
Rob Landley wrote:
> I notice that feature-removal-schedule.txt has CONFIG_FORCED_INLINING
> scheduled to go away most of a year ago. My question is what replaces it:
>
> Does #define inline __always_inline become the new standard and uses of
> __always_inline be removed, or should all instances of "inline" either be
> removed or replaced with __always_inline? (Or are there going to be two
> keywords meaning exactly the same thing going forward?)
it should be that we do not force gcc to inline on the "normal" inline
keyword, and we mark the cases that HAVE to be inlined for correctness
reasons as __always_inline.
On Wed, May 23, 2007 at 12:42:47PM -0700, Arjan van de Ven wrote:
> Rob Landley wrote:
>> I notice that feature-removal-schedule.txt has CONFIG_FORCED_INLINING
>> scheduled to go away most of a year ago. My question is what replaces it:
>> Does #define inline __always_inline become the new standard and uses of
>> __always_inline be removed, or should all instances of "inline" either be
>> removed or replaced with __always_inline? (Or are there going to be two
>> keywords meaning exactly the same thing going forward?)
>
> it should be that we do not force gcc to inline on the "normal" inline
> keyword, and we mark the cases that HAVE to be inlined for correctness
> reasons as __always_inline.
What about performance reasons?
We habe "inline" code in header files that heavily relies on being
nearly completely optimized away after being inlined.
Especially with -Os it could even sound logical for a compiler to never
inline a non-forced "inline"'d three line function with 2 callers.
And we need only two different inline levels (__always_inline and
"let the compiler decide"), not three (__always_inline, inline and
"let the compiler decide").
The rules are simple:
- every static function in a header file must be __always_inline
- no function in a C file should be marked as __always_inline/inline
- in extreme rare cases there might be exceptions from the latter
Your suggestion is possible, but please also send a patch that turns
every "inline" in header files into __always_inline...
cu
Adrian
--
"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
> - every static function in a header file must be __always_inline
Why? Why does it matter whether a function is defined in a .h file or
a .c file? Can't the compiler decide better than we can whether
something should be inlined or not?
Your argument seems to imply that we should never use the inline
keyword at all.
- R.
Adrian Bunk wrote:
>
> What about performance reasons?
> We habe "inline" code in header files that heavily relies on being
> nearly completely optimized away after being inlined.
fair
> Especially with -Os it could even sound logical for a compiler to never
> inline a non-forced "inline"'d three line function with 2 callers.
but you said "I Care about size more than performance". Your argument
is thus absolutely incorrect.
> The rules are simple:
> - every static function in a header file must be __always_inline
wrong.
>
> Your suggestion is possible, but please also send a patch that turns
> every "inline" in header files into __always_inline...
this is 1) insane and 2) if inlines in headers are so big gcc decides
to not inline them.. they're too big and don't belong in the header.
On Wed, 23 May 2007, Roland Dreier wrote:
> > - every static function in a header file must be __always_inline
>
> Why? Why does it matter whether a function is defined in a .h file or
> a .c file? Can't the compiler decide better than we can whether
> something should be inlined or not?
>
> Your argument seems to imply that we should never use the inline
> keyword at all.
i hate to be in the middle of one of these again, but i think i
initiated this topic way back when when i (like rob landley) asked why
that config option was still around when it's been listed for deletion
for a year.
regardless of its good or bad points, one way or the other, something
should be updated.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On May 23 2007 23:22, Adrian Bunk wrote:
>
>And we need only two different inline levels (__always_inline and
>"let the compiler decide"), not three (__always_inline, inline and
>"let the compiler decide").
"inline" is "let the compiler decide". If it is not, then it is "let the
compiler decide, based on my bias that I think it should be inlined".
Jan
--
On Thursday 24 May 2007 8:38 am, Robert P. J. Day wrote:
> On Wed, 23 May 2007, Roland Dreier wrote:
>
> > > - every static function in a header file must be __always_inline
> >
> > Why? Why does it matter whether a function is defined in a .h file or
> > a .c file? Can't the compiler decide better than we can whether
> > something should be inlined or not?
> >
> > Your argument seems to imply that we should never use the inline
> > keyword at all.
Do we ever use the "register" keyword anymore? I don't make "suggestions" to
gcc, I hit it with a clue-by-by four.
> i hate to be in the middle of one of these again, but i think i
> initiated this topic way back when when i (like rob landley) asked why
> that config option was still around when it's been listed for deletion
> for a year.
I'm actually trying to write documentation on it. Temporary copy at:
http://landley.net/kdocs/inline.html
> regardless of its good or bad points, one way or the other, something
> should be updated.
I'd be happy to just figure out what the policy is. It seems like
the "inline" keyword should no longer be used, and either say __always_inline
or leave it to the compiler. If there's a good counter-argument, I'd love to
hear it.
Rob
On Wed, May 23, 2007 at 02:28:56PM -0700, Roland Dreier wrote:
> > - every static function in a header file must be __always_inline
>
> Why? Why does it matter whether a function is defined in a .h file or
> a .c file? Can't the compiler decide better than we can whether
> something should be inlined or not?
>
> Your argument seems to imply that we should never use the inline
> keyword at all.
A function only belongs into a header file if we always want it inlined,
otherwise it belongs into a C file.
> - R.
cu
Adrian
--
"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
On Wed, May 23, 2007 at 02:31:33PM -0700, Arjan van de Ven wrote:
> Adrian Bunk wrote:
>> What about performance reasons?
>> We habe "inline" code in header files that heavily relies on being nearly
>> completely optimized away after being inlined.
>
> fair
>
>> Especially with -Os it could even sound logical for a compiler to never
>> inline a non-forced "inline"'d three line function with 2 callers.
>
> but you said "I Care about size more than performance". Your argument is
> thus absolutely incorrect.
Theoretically, you are right.
Practically, this would imply removing the CONFIG_CC_OPTIMIZE_FOR_SIZE
option several distributions currently enable by default since it has
been shown that it often generates faster code...
>> The rules are simple:
>> - every static function in a header file must be __always_inline
>
> wrong.
>
>> Your suggestion is possible, but please also send a patch that turns every
>> "inline" in header files into __always_inline...
>
> this is 1) insane and 2) if inlines in headers are so big gcc decides to
> not inline them.. they're too big and don't belong in the header.
Exactly.
So there's no point in having a non-forced inline.
cu
Adrian
--
"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
On Thu, May 24, 2007 at 06:29:39PM +0200, Jan Engelhardt wrote:
>
> On May 23 2007 23:22, Adrian Bunk wrote:
> >
> >And we need only two different inline levels (__always_inline and
> >"let the compiler decide"), not three (__always_inline, inline and
> >"let the compiler decide").
>
> "inline" is "let the compiler decide". If it is not, then it is "let the
> compiler decide, based on my bias that I think it should be inlined".
Wrong.
"static" is "let the compiler decide".
> Jan
cu
Adrian
--
"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
> A function only belongs into a header file if we always want it inlined,
> otherwise it belongs into a C file.
Again, why? Why don't we trust the compiler to decide if a function
should be inlined or not, even if the definition happens to be in a .h
file?
It seems like a perfectly valid optimization for the compiler to only
emit code once for a function and then call it where it is used, even
if that function happens to be defined in a .h file.
- R.
Adrian Bunk wrote:
> On Thu, May 24, 2007 at 06:29:39PM +0200, Jan Engelhardt wrote:
>> On May 23 2007 23:22, Adrian Bunk wrote:
>>> And we need only two different inline levels (__always_inline and
>>> "let the compiler decide"), not three (__always_inline, inline and
>>> "let the compiler decide").
>> "inline" is "let the compiler decide". If it is not, then it is "let the
>> compiler decide, based on my bias that I think it should be inlined".
>
> Wrong.
> "static" is "let the compiler decide".
>
and "inline" is "give the compiler a suggestion". Not more than that.
On Thursday 24 May 2007 12:29 pm, Jan Engelhardt wrote:
>
> On May 23 2007 23:22, Adrian Bunk wrote:
> >
> >And we need only two different inline levels (__always_inline and
> >"let the compiler decide"), not three (__always_inline, inline and
> >"let the compiler decide").
>
> "inline" is "let the compiler decide".
The compiler decides anyway. That's why we need a noinline to tell it _not_
to spontaneously inline things it shouldn't.
> If it is not, then it is "let the
> compiler decide, based on my bias that I think it should be inlined".
Things like unlikely() actually produce different code (and are, technically
speaking, workarounds for the high branch misprediction penalty in modern
processor designs).
Things like "register" are a hint to the compiler that it's free to ignore.
How often do we use the "register" keyword in Linux? Register allocation is
totally different on different processors, and deprived of context the hint
is almomst meaningless. If it doesn't guarantee anything and has far less of
a performance impact than the difference between -O2 and -Os (or between gcc
3.4 and 4.1), then it's probably an unnecessary complication.
Inlining is even worse because whether or not it's a performance win depends
on the L1 cache size, cache line size and alignment, L2 cache, DRAM fetch
latency, and so on. This varies all over the map within a given processor
line, let alone between processors.
If we actually need something inlined, we can tell it to do so reliably with
__always_inline (and change __always_inline to be MORE explicit each time gcc
breaks the previous way of saying "yes really inline it dammit"). If we can
live with it not being inlined, why not leave it to the compiler whether or
not to inline it?
Rob
Rob Landley wrote:
> If the compiler can emit a warning "inline insanely large", we can use that to
> fix it. But a warning is not the same as silently doing something other than
> what we told it to do.
It's not silent! that's what "inline" without the force is for!
Once you force it you shut the warning up!!!!
On Thursday 24 May 2007 1:14 pm, Roland Dreier wrote:
> > A function only belongs into a header file if we always want it inlined,
> > otherwise it belongs into a C file.
>
> Again, why? Why don't we trust the compiler to decide if a function
> should be inlined or not, even if the definition happens to be in a .h
> file?
Because the purpose of .h files is to be included in more than one .c file.
(Otherwise it should be a .c file.)
And if you #include a non-inlined definition in two .c files, the compiler
will emit two copies into two separate .o files. What you're hoping is that
the linker will notice they're identical and merge them, and last I checked I
couldn't even reliably get it to do that with constant strings.
> It seems like a perfectly valid optimization for the compiler to only
> emit code once for a function and then call it where it is used, even
> if that function happens to be defined in a .h file.
If we put it in a header, it's because we want it inlined. If we don't want
it inlined it SHOULDN'T BE IN THE HEADER.
If the compiler can emit a warning "inline insanely large", we can use that to
fix it. But a warning is not the same as silently doing something other than
what we told it to do.
> - R.
Rob
> And if you #include a non-inlined definition in two .c files, the compiler
> will emit two copies into two separate .o files. What you're hoping is that
> the linker will notice they're identical and merge them, and last I checked I
> couldn't even reliably get it to do that with constant strings.
No, I don't care if the linker merges it or not. In fact I hope that
maybe the compiler is smart enough to optimize the function for the
sites it's called from in a particular .c file.
But a function defined in a .h file had better be static, so it
shouldn't matter if there are two copies of it in the final linked
image (any more than it matters if there are 100 inlined copies of it).
On Thu, May 24, 2007 at 10:14:41AM -0700, Roland Dreier wrote:
> > A function only belongs into a header file if we always want it inlined,
> > otherwise it belongs into a C file.
>
> Again, why? Why don't we trust the compiler to decide if a function
> should be inlined or not, even if the definition happens to be in a .h
> file?
>
> It seems like a perfectly valid optimization for the compiler to only
> emit code once for a function and then call it where it is used, even
> if that function happens to be defined in a .h file.
The compiler will always inline it when it's called once from a C file,
and it might not inline it there when it's called more than once from
another C file. So in the end, we have it not only out-of-line but also
inlined in several places.
Functions in header files should either be extremely short so that
inlining them makes sense, or always optimize to something extremely
short after being inlined.
If it's an optimization to emit the code only once, then it's a bug that
it's in a header file.
> - R.
cu
Adrian
--
"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
On Thu, May 24, 2007 at 10:55:34AM -0700, Roland Dreier wrote:
> > And if you #include a non-inlined definition in two .c files, the compiler
> > will emit two copies into two separate .o files. What you're hoping is that
> > the linker will notice they're identical and merge them, and last I checked I
> > couldn't even reliably get it to do that with constant strings.
>
> No, I don't care if the linker merges it or not. In fact I hope that
> maybe the compiler is smart enough to optimize the function for the
> sites it's called from in a particular .c file.
>
> But a function defined in a .h file had better be static, so it
> shouldn't matter if there are two copies of it in the final linked
> image (any more than it matters if there are 100 inlined copies of it).
The problem is that inline functions in headers are intended to be
called from different C files.
gcc might not inline it in the C files where it is called more than
once.
But it will always inline it if it's called only once.
One of both will be suboptimal, but from gcc's perspective it was
optimal.
cu
Adrian
--
"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
On Thursday 24 May 2007 1:47 pm, Arjan van de Ven wrote:
> Rob Landley wrote:
> > If the compiler can emit a warning "inline insanely large", we can use
that to
> > fix it. But a warning is not the same as silently doing something other
than
> > what we told it to do.
>
> It's not silent! that's what "inline" without the force is for!
> Once you force it you shut the warning up!!!!
So presumably, a debug option could #define __always_inline to just "inline"
in order to get warning messages to look at?
Rob
> The problem is that inline functions in headers are intended to be
> called from different C files.
>
> gcc might not inline it in the C files where it is called more than
> once.
>
> But it will always inline it if it's called only once.
>
> One of both will be suboptimal, but from gcc's perspective it was
> optimal.
Yes, we could probably get huge benefits from --combine and/or
-fwhole-program to let gcc see more than one file at a time.
But I still don't see the issue with having gcc do the best it can on
each file it compiles. If you force the inlining, then that means
that on files where not inlining was better, you've forced gcc to
generate worse code. (I don't see how not inlining could be locally
better on a single file but globally worse, even though it generated
better code on each compiled file)
On Thu, May 24, 2007 at 11:32:07AM -0700, Roland Dreier wrote:
> > The problem is that inline functions in headers are intended to be
> > called from different C files.
> >
> > gcc might not inline it in the C files where it is called more than
> > once.
> >
> > But it will always inline it if it's called only once.
> >
> > One of both will be suboptimal, but from gcc's perspective it was
> > optimal.
>
> Yes, we could probably get huge benefits from --combine and/or
> -fwhole-program to let gcc see more than one file at a time.
>
> But I still don't see the issue with having gcc do the best it can on
> each file it compiles. If you force the inlining, then that means
> that on files where not inlining was better, you've forced gcc to
> generate worse code. (I don't see how not inlining could be locally
> better on a single file but globally worse, even though it generated
> better code on each compiled file)
Can you give examples where for one function it differs between
different C files whether it should be inlined or not?
cu
Adrian
--
"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