Re: [boost] BOOST_FORCE_INLINE

Subject: Re: [boost] BOOST_FORCE_INLINE
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-10-09 21:08:39

On Sun, Oct 9, 2011 at 8:51 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> 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?

Shouldn't there be documentation that describes when to use it and
when not to use it? I guess my main concern is that it might be used
inappropriately if the name is the only guideline developers have.

--Beman