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
> 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
>>> specifier, while __attribute__((always_inline)) can be placed in various
>>> places like other GCC attributes, but only has an effect if the function
>>> 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
> - 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
> - 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk