Register Allocation Heuristics

blackmarlin@asean-mail.com (C)
15 May 2003 11:38:01 -0400

          From comp.compilers

Related articles
Register Allocation Heuristics blackmarlin@asean-mail.com (2003-05-15)
Re: Register Allocation Heuristics touati@prism.uvsq.fr (TOUATI Sid) (2003-05-18)
Re: Register Allocation Heuristics blackmarlin@asean-mail.com (2003-05-24)
Re: Register Allocation Heuristics mayan@sandbridgetech.com (2003-05-29)
| List of all articles for this month |

From: blackmarlin@asean-mail.com (C)
Newsgroups: comp.compilers
Date: 15 May 2003 11:38:01 -0400
Organization: http://groups.google.com/
Keywords: registers, optimize, question
Posted-Date: 15 May 2003 11:38:00 EDT

On a paper I am writing I have made the assertion that a register
caching hardware optimisation (caching a subset of a large slow
register file in a small set of fast registers) could result in
thrashing, I suspect some register allocation heuristics would further
compound this problem; that is by allocating registers so that all are
read on adverage the same number of times instead of a few registers
being read much more than others. (Some programmes, of course, would
produce such a usage pattern, I however am looking for register
allocation heurisitics which could worsen it).


Please could you direct me to some papers detailing widely used
register allocation heuristics (such as graph colouring), or supply
names of well known researchers in that field (in order for me to find
such papers) - I have looked on citeseer, but am not sufficiently
familiar with this area of compiler research to get the search to
produce useful results.


Ideally could you point me to an algorithm which tends to produce a
uniform distribution of registers and does not take into account the
number of reads or writes to the register file - this I would suspect
would produce such an effect in certain programmes.


With thanks in advance.


C 2003/5/7


Post a followup to this message

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