Re: [boost] BOOST_FORCE_INLINE

Subject: Re: [boost] BOOST_FORCE_INLINE
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-10-10 05:32:30

On 10/10/2011 10:46, Domagoj Saric wrote:
> On 10.10.2011. 8:22, Jeffrey Lee Hellrung, Jr. wrote:
>> +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.
>
> Well Mathias has already outlined the major reasons. That seems like
> quite sufficient documentation. If a developer is performance conscious
> and notices one the outlined problems in the codegen he can simply try
> the force inline approach and see if it helps. I don't see where a
> problem could lie there or a reason for wasting too much time discussing
> something so simple. Otherwise one could question any existing part of
> the language by pointing that it could be abused (unintentionally or
> otherwise).
>
> I don't know of a "study" related to forceinline, but in this case it
> arose as a (partial) solution to the problems listed by Mathias in the
> development of the NT2 (and thuse Boost.SIMD and Boost.Dispatch)
> libraries. These were discussed on the NT2 dev mailing list an on #nt2
> so maybe someone can present logs of these discussions if you are
> interested...

Boost.SIMD is particularly sensitive to inlining.

The arguments of each function should be put into SSE registers, but 
when a function is not inlined, the registers are copied to the stack 
and the addresses on the stack are passed to the function.

The ABI forces this behaviour because the types used to represent the 
registers are structures.

On another note, inlining stuff has proven useful to ignore a certain 
amount of function jumping with Boost.Dispatch when running code in a 
debugger.