Predict register usage

Tim Frink <>
Fri, 25 Apr 2008 13:56:25 +0000 (UTC)

          From comp.compilers

Related articles
Predict register usage (Tim Frink) (2008-04-25)
Re: Predict register usage (Chris F Clark) (2008-04-25)
Predict register usage (Inderaj Bains) (2008-04-26)
Re: Predict register usage (Sid Touati) (2008-04-28)
Re: Predict register usage (2008-05-02)
Re: Predict register usage (2008-05-02)
Re: Predict register usage (=?ISO-8859-1?Q?Bj=F6rn_Franke?=) (2008-05-09)
| List of all articles for this month |

From: Tim Frink <>
Newsgroups: comp.compilers
Date: Fri, 25 Apr 2008 13:56:25 +0000 (UTC)
Organization: CS Department, University of Dortmund, Germany
Keywords: registers, question
Posted-Date: 25 Apr 2008 10:16:31 EDT


When the optimization inline extension is performed on a high-level
intermediate representation or on a low-level IR before register
allocation, the final result for the inlined code after the register
allocation is not known. Thus, it might happen that due to the
increased register pressure after inlining, spill code must be added
heavily leading to a worse performance than before the
optimization. Do you know of any approaches which try to predict the
resulting spill code added by a register allocation when inlining is
done for a particular function?

My idea was that lifetime analyses might be used for that purpose. One
could find out how many variables (in high-level) or register are life
across a call. This is an indication for spill code candidates. Based
on this one could develop some heuristics that omit inlining for
functions that are supposed to add too much spilling. What do you
think about this idea?

Are there in general any approaches that try to predict the register
usage/spill code generation in the generated assembly code exclusively
based on the consideration of the source code (or high-level code) and
the knowledge of the underlying hardware the compiler produces code
for? This is probably very hard since it requires a deep knowledge of
the register allocator.


Post a followup to this message

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