Re: Register allocation and instruction scheduling

: 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

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