Re: Register allocation and instruction scheduling

mikesw@whiterose.net (M Sweger)
27 Jan 1999 12:11:14 -0500

          From comp.compilers

Related articles
Register Allocation and Instruction Scheduling nandu@cs.clemson.edu (1994-03-23)
Register allocation and instruction scheduling mikesw@whiterose.net (1999-01-17)
Re: Register allocation and instruction scheduling greened@zip.eecs.umich.edu (David A. Greene) (1999-01-19)
Re: Register allocation and instruction scheduling bob.morgan@digital.com (1999-01-20)
Re: Register allocation and instruction scheduling greened@zip.eecs.umich.edu (David A. Greene) (1999-01-22)
Re: Register allocation and instruction scheduling bob.morgan@digital.com (1999-01-25)
Re: Register allocation and instruction scheduling mikesw@whiterose.net (1999-01-27)
Re: Register allocation and instruction scheduling zalman@netcom.com (1999-01-27)
Re: Register allocation and instruction scheduling anton@mips.complang.tuwien.ac.at (1999-01-31)
Re: Register allocation and instruction scheduling adrian@dcs.rhbnc.ac.uk (1999-02-01)
| List of all articles for this month |
From: mikesw@whiterose.net (M Sweger)
Newsgroups: comp.compilers
Date: 27 Jan 1999 12:11:14 -0500
Organization: DataHaven Project, Inc (http://www.dhp.com)
References: 99-01-055 99-01-076 99-01-077 99-01-092
Keywords: registers, architecture, optimize

: If we are trying to put resources on a chip there are always
: limitations. Furthermore the bigger the register file, the slower the
: access to registers and the more control structure controlling the
: registers. So there are always limitations. The compiler must be
: prepared to keep the limitations from hurting performance. In other
: words there may not be enough physical registers to do any sequence of
: instructions and register renaming situations.


: In fact, it is probably a bad idea to have enough physical registers
: for all situations. That ties of chip real estate and control logic
: that would rarely be used. Instead you want enough physical registers
: to guarantee that maximum performance can be gained and then have the
: compilers gain that performance.


Then at what point does a general purpose processor with N number of
registers then considered a vector processor with N number of
registers per register file? Or is it based on general purpose=one
register file of N registers vs. a vector processor=more than one
register file of N registers each? Once this distinction is made, then
the compiler is transformed from one of general purpose to a
vectorized compiler. I assume then that the register allocation graph
coloring techniques are applied twice: once for the allocating the
register file, and then again to allocate the register in that
particular register file.


--
Mike,
mikesw@whiterose.net


Post a followup to this message

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