Status of CONFIG_FORCED_INLINING?

Status of CONFIG_FORCED_INLINING?

[Rob Landley]

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

Re: Status of CONFIG_FORCED_INLINING?

[Arjan van de Ven]

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.

Re: Status of CONFIG_FORCED_INLINING?

[Adrian Bunk]

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

Re: Status of CONFIG_FORCED_INLINING?

[Roland Dreier]

 > - 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.

Re: Status of CONFIG_FORCED_INLINING?

[Robert P. J. Day]

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
========================================================================

Re: Status of CONFIG_FORCED_INLINING?

[Rob Landley]

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

Re: Status of CONFIG_FORCED_INLINING?

[Adrian Bunk]

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

Re: Status of CONFIG_FORCED_INLINING?

[Roland Dreier]

 > 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.

Re: Status of CONFIG_FORCED_INLINING?

[Rob Landley]

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

Re: Status of CONFIG_FORCED_INLINING?

[Arjan van de Ven]

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!!!!

Re: Status of CONFIG_FORCED_INLINING?

[Rob Landley]

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

Re: Status of CONFIG_FORCED_INLINING?

[Roland Dreier]

 > 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).

Re: Status of CONFIG_FORCED_INLINING?

[Adrian Bunk]

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

Re: Status of CONFIG_FORCED_INLINING?

[Roland Dreier]

 > 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)

Re: Status of CONFIG_FORCED_INLINING?

[Adrian Bunk]

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

Re: Status of CONFIG_FORCED_INLINING?

[Adrian Bunk]

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

Re: Status of CONFIG_FORCED_INLINING?

[Arjan van de Ven]

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.

Re: Status of CONFIG_FORCED_INLINING?

[Adrian Bunk]

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

Re: Status of CONFIG_FORCED_INLINING?

[Jan Engelhardt]

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
-- 

Re: Status of CONFIG_FORCED_INLINING?

[Adrian Bunk]

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

Re: Status of CONFIG_FORCED_INLINING?

[Arjan van de Ven]

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.

Re: Status of CONFIG_FORCED_INLINING?

[Rob Landley]

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