December 07, 2005
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


December 07, 2005
"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.


December 07, 2005
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)
December 07, 2005
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
December 07, 2005
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.
Top | Discussion index | About this forum | D home