|optimization and register allocation sastry@GODEL.MIEL.MOT.COM (1995-02-24)|
|Re: optimization and register allocation davidm@Rational.COM (1995-02-28)|
|Re: optimization and register allocation firstname.lastname@example.org (1995-03-04)|
|Re: optimization and register allocation email@example.com (1995-03-06)|
|From:||firstname.lastname@example.org (Preston Briggs)|
|Date:||Mon, 6 Mar 1995 18:08:53 GMT|
davidm@Rational.COM (David Moore) writes:
>I have heard it said that live range splitting is not usually
>worth the expense. How true is this?
I spent a couple of years experimenting with ways to do live range
splitting in the context of Chaitin's allocator. I tried several
approaches, but the results were not consistent; that is, for some
routines I got great results (big reductions in spill overhead), but
other routines would get worse. Note that allocation time wasn't a
problem; instead, spill overhead (including all the register-register
copies) was the basic bottleneck.
Actually, I had good results with the rematerialization work, which is
sort of a special case of splitting.
A lot of my ideas are described in my thesis (if you want to know what
to avoid :-) There's also a brief note describing a basic flaw in my
implementation that perhaps incorrectly prejudiced my results
Others (e.g., Chow & Hennessy and Callahan & Koblenz) are much happier
with their splitting allocators. Indeed, we use Callahan & Koblenz
>Has anyone investigated doing splitting
>only in response to register pressure, or only for values
>that are dead in loops but would be in registers there?
Chow & Hennessy split only in response to register pressure.
In the 2nd part of your question, I assume you mean "values that are
live across a loop, but never referenced or defined in the loop." I
tried it, and some variations, and never got consistent results. But
this was all in the context of Chaitin's allocator. Chow & Hennessy
and Callahan & Koblenz take advantage of this sort of situation.
Return to the
Search the comp.compilers archives again.