register allocation

David Lindauer <camille@bluegrass.net>
12 Nov 2005 15:44:26 -0500

          From comp.compilers

Related articles
[17 earlier articles]
Re: Register allocation kamalp@acm.org (2004-08-13)
Register allocation thibault.langlois@di.fc.ul.pt (thibault.langlois@di.fc.ul.pt) (2005-05-13)
Re: Register allocation rgd00@doc.ic.ac.uk (Rob Dimond) (2005-05-16)
Re: Register allocation torbenm@diku.dk (2005-05-18)
Re: Register allocation thibault.langlois@di.fc.ul.pt (thibault.langlois@di.fc.ul.pt) (2005-05-20)
Re: Register allocation c3riechers@adelphia.com (Chuck Riechers) (2005-05-21)
register allocation camille@bluegrass.net (David Lindauer) (2005-11-12)
register allocation dgb@cs.washington.edu (1989-11-22)
Re: register allocation larus@primost.wisc.EDU (1989-11-24)
Register Allocation napi@rangkom.MY (1990-02-17)
Re: Register Allocation cik@l.cc.purdue.edu (1990-02-15)
Re: Register Allocation wendyt@cs.washington.edu (1990-02-26)
Re: Register Allocation Moss@cs.umass.edu (1990-02-25)
[5 later articles]
| List of all articles for this month |

From: David Lindauer <camille@bluegrass.net>
Newsgroups: comp.compilers
Date: 12 Nov 2005 15:44:26 -0500
Organization: news.bluegrass.net
Keywords: registers
Posted-Date: 12 Nov 2005 15:44:26 EST

hi,


I'm working from robert morgan 'building an optimizing compiler' and
making a register allocator. The book is designed around Risc
processors, but I'm trying to see what happens when I use it on a
limited register CISC processor like the x86.


For the most part I can get the algorithms working, which include some
local optimization, live variable analysis, and the register
allocation. However I've come up with a problem where maxing out the
registers to use to store globals (variables used across block
boundaries) confuses the spilling algorithms.


basically I'm compiling the following C language code:


int bb()
{
  int a,b,c,d,e,f,g,h;
  a = 1 ;
  b = 2 ;
  c = 3 ;
  d = 4 ;
  e = 5 ;
  f = 6 ;
  g = 7 ;
  h = 8 ;
  if (d)
    d++;
  aa(a,b,c,d,e,f,g,h);
}


Bear in mind all the variables are globals, and there are only 6
available registers in my implementation. it generates good
intermediate code up to the call of aa(), after which I get the
following:


;
; Line 50: aa(a,b,c,d,e,f,g,h);
;
  TEMP10(unknown).I = **DUMMY3:LINK(-12).I
  **DUMMY5:LINK(-4).I = TEMP10(unknown).I
  PARM TEMP10(unknown).I
  TEMP10(unknown).I = **DUMMY5:LINK(-4).I
  PARM _g[TEMP1]:LINK(EDI).I
  PARM _f[TEMP2]:LINK(EBX).I
  PARM _e[TEMP3]:LINK(ECX).I
  PARM _d[TEMP4]:LINK(ESI).I
  PARM _c[TEMP5]:LINK(EAX).I
  PARM _b[TEMP6]:LINK(EDX).I
  TEMP11(EAX).I = **DUMMY2:LINK(-16).I
  PARM TEMP11(EAX).I
  GOSUB #_aa:RAM.A


basically there has been two spills while processing 'h'... one during
global allocation and one during local. DUMMY3 is the result of the
global spill, DUMMY5 the result of the local one. During the local
allocation it can't find a register because the spill algorithm says go
to the beginning of the block and find the earliest (local) temporary
register that is unused past the current point in the block and spill
it. But we are already at the beginning of the block... I think it
would work fine if I hadn't already maxed out the register usage with
globals, or if it had chosen something other than 'h' to spill. While I
could make the global allocator not spill 'h' in these circumstances, I
don't want to do it because I am concerned another ordering of the
variables in the call to 'a' would result in the same problem.


The book doesn't really talk about the consequences when the registers
are maxed out by the global allocation algorithm, and I'm not sure what
direction to go in here. I'm thinking that if I alter the spill
algorithm slightly to work also when the spilled register is AFTER the
current line of code instead of before, that would work, but am unsure
if that would have other negative consequence. Can anyone shed some
light on this for me?


Thanks,


David


.



Post a followup to this message

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