I know; that sounds like a headline from BBSpot. Still, -inline actually shrank an exec by half a K. All that call overhead is killing us :-)

Classic headline: http://www.bbspot.com/News/2000/5/clock_rift.html

"Kris" <fu@bar.com> wrote in message news:dn5aih$1fq$1@digitaldaemon.com...
> I know; that sounds like a headline from BBSpot. Still, -inline actually shrank an exec by half a K. All that call overhead is killing us :-)

Many inline functions have smaller code generated for them than they require in stack frame setup/teardown code. Also, inlining enables better register allocation.

Walter Bright wrote:
> "Kris" <fu@bar.com> wrote in message news:dn5aih$1fq$1@digitaldaemon.com...
> 
>>I know; that sounds like a headline from BBSpot. Still, -inline actually
>>shrank an exec by half a K. All that call overhead is killing us :-)
> 
> 
> Many inline functions have smaller code generated for them than they require
> in stack frame setup/teardown code. Also, inlining enables better register
> allocation.
> 
> 

Not to mention the possible pipelining benefits on modern processors and the possible preservation of locality of reference (not destroying the cache)

Walter Bright skrev:
> "Kris" <fu@bar.com> wrote in message news:dn5aih$1fq$1@digitaldaemon.com...
>> I know; that sounds like a headline from BBSpot. Still, -inline actually
>> shrank an exec by half a K. All that call overhead is killing us :-)
> 
> Many inline functions have smaller code generated for them than they require
> in stack frame setup/teardown code. Also, inlining enables better register
> allocation.
> 
> 
Out of curiosity; the spec speaks of compiler choosing when to do inlining, on what premises is this actually done?

I guess you Walter does not have the answer, but is this also done with GDC in some special way or is it left to normal GCC behavior (enabled by -finline-functions and -O3)?

// Fredrik Olsson

Fredrik Olsson wrote:
> Walter Bright skrev:
> 
>> "Kris" <fu@bar.com> wrote in message news:dn5aih$1fq$1@digitaldaemon.com...
>>
>>> I know; that sounds like a headline from BBSpot. Still, -inline actually
>>> shrank an exec by half a K. All that call overhead is killing us :-)
>>
>>
>> Many inline functions have smaller code generated for them than they require
>> in stack frame setup/teardown code. Also, inlining enables better register
>> allocation.
>>
>>
> Out of curiosity; the spec speaks of compiler choosing when to do inlining, on what premises is this actually done?
> 
> I guess you Walter does not have the answer, but is this also done with GDC in some special way or is it left to normal GCC behavior (enabled by -finline-functions and -O3)?
> 
> // Fredrik Olsson

I would assume the language SPEC makes no assumptions as to the implementation of inlining choosing.  But if you're curious as to how the reference implementation chooses, you can look at the DMD front-end's source code.

I'd recommend starting at dmd/src/dmd/inline.c and going from there.  On a quick glance it seems to be estimating costs per operation and totalling them up for the function in question.  If the total cost is less than some threshold, then the function can be inlined, otherwise it's assumed to be not worth the inlining effort.  This is a good, general, heuristic approach to things and should work for most cases.