Subject: Re: [boost] BOOST_FORCE_INLINE
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-10-10 02:22:47
On Sun, Oct 9, 2011 at 6:08 PM, Beman Dawes <bdawes_at_[hidden]> wrote:
> 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
> >>> places like other GCC attributes, but only has an effect if the
> >>> 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
> > 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
> > make applications that depend a lot on meta-programming to run at
> > performance
> > - compiling for size is not always very aggressive with inlining, but a
> > 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
> > required by a function call, which is important to avoid in low-level
> > 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.
+1, my thoughts exactly, Beman. Can anyone provide any links to a case
study or something similar investigating the effects of forcing inlining?
I'm definitely interested to see what real effects this could have.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk