Re: Register pressure and inlining

Ray Dillinger <bear@sonic.net>
Wed, 12 Nov 2008 08:20:01 -0800

          From comp.compilers

Related articles
Register pressure and inlining linuxkaffee_@_gmx.net (Stephan Ceram) (2008-11-08)
Re: Register pressure and inlining jeremy.wright@microfocus.com (Jeremy Wright) (2008-11-09)
RE: Register pressure and inlining murugesh@acmet.com (Murugesh) (2008-11-10)
Re: Register pressure and inlining liangkun1983@gmail.com (Alex L.K) (2008-11-12)
Re: Register pressure and inlining armelasselin@hotmail.com (Armel) (2008-11-12)
Re: Register pressure and inlining bear@sonic.net (Ray Dillinger) (2008-11-12)
Re: Register pressure and inlining cdg@nullstone.com (Christopher Glaeser) (2008-11-12)
Re: Register pressure and inlining wimbleweather@verizon.net (Bob Morgan) (2008-12-17)
| List of all articles for this month |

From: Ray Dillinger <bear@sonic.net>
Newsgroups: comp.compilers
Date: Wed, 12 Nov 2008 08:20:01 -0800
Organization: Organized? Seems unlikely.
References: 08-11-036 08-11-045 08-11-047
Keywords: optimize, registers
Posted-Date: 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
the spill/recover.


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.


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
compiler


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.




                                                                Bear


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.



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.