|why not inline all functions? email@example.com (Mark Sanvitale) (1998-06-09)|
|Re: why not inline all functions? cliff.click@Eng.Sun.COM (Clifford Click) (1998-06-11)|
|Re: why not inline all functions? firstname.lastname@example.org (Phillip Toland) (1998-06-11)|
|Re: why not inline all functions? email@example.com (Joerg Schoen) (1998-06-11)|
|Re: why not inline all functions? firstname.lastname@example.org (Ben Elliston) (1998-06-11)|
|Re: why not inline all functions? email@example.com (Andy Ayers) (1998-06-11)|
|Re: why not inline all functions? firstname.lastname@example.org (1998-06-11)|
|Re: why not inline all functions? email@example.com (Thomas Niemann) (1998-06-11)|
|[3 later articles]|
|From:||Clifford Click <cliff.click@Eng.Sun.COM>|
|Date:||11 Jun 1998 16:10:03 -0400|
Mark Sanvitale wrote:
> Functions are great for making written code (C, C++, etc.) mode
> readable and structured, however, they do not seem to make much sense
> when you get down to the raw machine code which actually is executed
> by a processor.
> As far as my understanding of the matter goes, the most basic way to
> slow down a processor is to make it execute an instruction besides the
> one immediately following the current instruction, thus, why not make
> a compiler which turns every function into an inline function?
> "computer geek and movie freak"
> [ ... code bloat ... -John]
Yes, code bloat is one of the main gating factors for inlining.
Another is register pressure - function calls tend to use special
fast-path means for spilling/loading a large number of registers.
Standard allocators tend to spill one-by-one. Allocators also tend to
make fairly bad code when a large amount of spilling is required.
This "bad spilling" works on most RISCs because large register files
means spill code is rare --- as long as you throttle inlining.
Cliff Click Compiler Designer and Researcher
cliffc at acm.org JavaSoft
(408) 863-3266 MS UCUP02-302
Return to the
Search the comp.compilers archives again.