Re: [boost] BOOST_FORCE_INLINE

Subject: Re: [boost] BOOST_FORCE_INLINE
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-10-09 20:51:58

On 10/10/2011 02:02 AM, Olaf van der Spek wrote:
> On Mon, Oct 10, 2011 at 1:50 AM, Mathias Gaunard
> <mathias.gaunard_at_[hidden]>  wrote:
>> They're slightly different: __forceinline works just like the normal inline
>> specifier, while __attribute__((always_inline)) can be placed in various
>> places like other GCC attributes, but only has an effect if the function is
>> also inline.
>
> Shouldn't the decision to inline be left to the compiler?

The point of that macro is to override the compiler analysis.

Compilers are not perfect, so it is beneficial to mark to functions 
inline manually for a variety of reasons:

  - you'll get an error or warning if the compiler cannot inline it
  - you can still get the inlining in debug mode, which can be necessary 
to make applications that depend a lot on meta-programming to run at 
acceptable performance
  - compiling for size is not always very aggressive with inlining, but 
a lot of meta-programming things rely a lot on aggressive inlining to happen
  - for codebases with a lot of forwarding the compiler can easily get 
confused
  - inlining doesn't seem to take into account the costs of register 
spilling required by a function call, which is important to avoid in 
low-level code.

Do people generally agree it is ok to add this in Boost.Config, and 
maybe make some key libraries use it?