|Register pressure and inlining linuxkaffee_@_gmx.net (Stephan Ceram) (2008-11-08)
|Re: Register pressure and inlining firstname.lastname@example.org (Jeremy Wright) (2008-11-09)
|RE: Register pressure and inlining email@example.com (Murugesh) (2008-11-10)
|Re: Register pressure and inlining firstname.lastname@example.org (Alex L.K) (2008-11-12)
|Re: Register pressure and inlining email@example.com (Armel) (2008-11-12)
|Re: Register pressure and inlining firstname.lastname@example.org (Ray Dillinger) (2008-11-12)
|Re: Register pressure and inlining email@example.com (Christopher Glaeser) (2008-11-12)
|Re: Register pressure and inlining firstname.lastname@example.org (Bob Morgan) (2008-12-17)
|Ray Dillinger <email@example.com>
|Wed, 12 Nov 2008 08:20:01 -0800
|Organized? Seems unlikely.
|08-11-036 08-11-045 08-11-047
|12 Nov 2008 13:25:33 EST
Alex L.K wrote:
> The spilling code in this example does not hurt performance.
> Is there any example that inlining acctually causes performance loss?
Honestly, I don't think that warning (inlining code may increase
register pressure and thereby reduce performance) is really still
"real" with most compilers. It may be just folklore left over
from an earlier state of the art when it was true.
You see, it wasn't always normal for compilers to do register spills
in mid-function. They figured out a mapping of registers to variables
during compilation and used that mapping for the whole function. And
whatever variables weren't mapped to registers they placed in (much
slower) main memory.
Inlining a function that had its own variables inhibited the normal
spill that happened at function call, and resulted in a longer function
with more variables - some of which frequently had to be mapped in
main memory. You did this to avoid the time spent spilling and
restoring, and the compilers would put the least-used variables in
main memory so it was often a good idea. But if something that needed
to be read or written "a lot" got mapped into main memory instead of
to a register, it could be counterproductive because you'd spend more
time waiting for I/O on that variable than you would have spent on
But this position became untenable as the gap in performance between
main memory and registers widened in the 90's and 00's, and optimizing
register spills became increasingly important. Consequently, a lot of
very smart people spent a lot of time and effort figuring out methods
and metrics for optimizing them, and implementing those methods in
Modern compilers are much better at deciding when and where register
spills are needed, and will do it in the middle of a function if it
saves time or not bother doing it on a function call if they can
avoid it. So I think the warning about which you're enquiring is
probably no longer true in most cases. Either you're using a modern
They are also much better at figuring out where inlining is justified
and in languages that have 'inline' directives they may ignore them
anyway, in the same way many compilers have been ignoring 'register'
directives since the late '80s.
PS. A lot of other very smart people spent a lot of time and effort
figuring out write-through caches and assorted hardware to "fake"
faster access to main memory, and modern hardware is much better
at simulating fast access to memory when something gets mapped
there. These days we're seeing the benefits of both things, really.
Return to the
Search the comp.compilers archives again.