• Kris (3/3) Dec 06 2005 I know; that sounds like a headline from BBSpot. Still, -inline actually...
• Walter Bright (4/6) Dec 06 2005 Many inline functions have smaller code generated for them than they req...
• James Dunne (4/15) Dec 06 2005 Not to mention the possible pipelining benefits on modern processors and...
• Fredrik Olsson (7/16) Dec 07 2005 Out of curiosity; the spec speaks of compiler choosing when to do
• James Dunne (11/35) Dec 07 2005 I would assume the language SPEC makes no assumptions as to the

"Kris" <fu bar.com> writes:

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 

"Walter Bright" <newshound digitalmars.com> writes:

"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.

James Dunne <james.jdunne gmail.com> writes:

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)

Fredrik Olsson <peylow treyst.se> writes:

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

James Dunne <james.jdunne gmail.com> writes:

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.