Related articles |
---|
Extended Optimization using Peephole strategy bear@sonic.net (Ray S. Dillinger) (1996-11-05) |
Re: Extended Optimization using Peephole strategy zs@munta.cs.mu.OZ.AU (1996-11-06) |
"Semantic Retention": Extended Optimization using Peephole strategy jhummel@crispix.ICS.UCI.EDU (Joe Hummel) (1996-11-07) |
Re: Extended Optimization using Peephole strategy alcino@mundau.dcc.ufal.br (1996-11-10) |
Re: Extended Optimization using Peephole strategy jgm@CS.Cornell.EDU (Greg Morrisett) (1996-11-12) |
From: | "Ray S. Dillinger" <bear@sonic.net> |
Newsgroups: | comp.compilers |
Date: | 5 Nov 1996 23:31:51 -0500 |
Organization: | Cognitive Dissidents |
Keywords: | optimize, question |
I am writing a compiler for scheme, and I've hit upon a strategy which
seems new to me -- Wasn't covered in any of my classwork or reference
books. At the same time, it's fairly simple, and I was wondering if
someone's done it before, or whether I ought to write a paper on it?
Basically, I am using a peephole optimizer to do most of the
optimizing job -- but with additional information coded in the
"instruction set" I'm using for my intermediate form, including
variable lifetime expiry, semantic binding extents for variables and
environments, and so on. By moving these "instructions" around in the
program according to rules established for ordinary code motion and
loop truncation, I get some pretty sophisticated optimizations "for
free" using a provably correct methodology. In particular, my
compiler figured out for itself that it didn't need to allocate extra
stack frames in the case of tail recursion -- which surprised me; I
went to add a feature and found that it didn't change the generated
code at all.
Bear
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.