Related articles |
---|
TEMPORARIES in Reg. Alloc. napi@rangkom.MY (1991-04-02) |
Re: TEMPORARIES in Reg. Alloc. pardo@cs.washington.edu (1991-04-02) |
Newsgroups: | comp.compilers |
From: | pardo@cs.washington.edu (David Keppel) |
Keywords: | design, registers, optimize |
Organization: | Computer Science & Engineering, U. of Washington, Seattle |
References: | <401@rangkom.MY> |
Date: | Tue, 2 Apr 91 13:12:20 -0800 |
napi@rangkom.MY writes:
>[How about letting temporaries fight for registers rather than
> just pre-allocating a fixed number of registers?]
My off-the-hat response:
If your IR contains only primitive machine operations and if
register allocation is done on the IR, then that's probably
what you're doing already. For example:
C:
x = y + z * x;
IR:
t1 = z * x;
x = y * t1;
Loop induction and unrolling are machine-independent optimizations (that
may have machine-dependent profitability) which can add and delete program
variables and can add long- lived temporaries. Most compilers will
probably (I'm guessing) treat those compiler-introduced temporaries as
variables, at for the register allocator.
With statement-level or basic-block optimizations, most temporaries are
``very temps'' and only one or two are needed at any given time. Thus, on
machines with a large number (~30) of registers, the differences between
pre-allocation and integrated allocation will be small. For sophisticated
optimizations, I do not know and do not care to guess.
Merging variables and temporaries can, in general, cause a phase ordering
conflict with instruction selection. Which instruction sequence the
compiler picks may depend on how many registers are available. How many
registers are avaialible depends on how many temporaries are in use. How
many temporaries are in use depends on the instruction sequence.
;-D on ( Optim eyes ) Pardo
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.