Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [20 earlier articles] |
| Re: Intermediate Representation staff@cadlab.sublink.org (1990-08-18) |
| Re: Intermediate Representation ok@goanna.cs.rmit.OZ.AU (1990-08-20) |
| intermediate representation han@cs.rochester.edu (1991-02-20) |
| Re: intermediate representation lavinus@csgrad.cs.vt.edu (1991-02-22) |
| Re: intermediate representation mike@vlsivie.tuwien.ac.at (1991-02-23) |
| Re: intermediate representation rfg@ncd.com (1991-02-26) |
| Re: intermediate representation megatest!djones@decwrl.dec.com (1991-02-27) |
| Re: intermediate representation tarvydas@turing.toronto.edu (1991-03-04) |
| Newsgroups: | comp.compilers |
| From: | megatest!djones@decwrl.dec.com (Dave Jones) |
| Keywords: | optimize, design |
| Organization: | Megatest Corporation, San Jose, Ca |
| References: | <4106@lupine.NCD.COM> |
| Date: | 27 Feb 91 20:12:26 GMT |
As you know, there are lots of optimizations that can be described in a
machine-independent way as correctness-preserving algorithm-transformations.
You really want to work those optimizations on the machine-independent
intermediate representation, but whether or not they really win or lose is
machine-dependent. It looks like a sitch where the "front end" and "back end"
need to collaborate, rather than run one after the other. I recently wrote a
special-purpose Pascal compiler on that principle, and I've started my second
"back end" for it (SPARC). But alas, the application does not warrant
investing much in optimization at this time, because the Pascal layers of
these application programs account for a very small percentage of the
execution-time. So I don't have any war stories to tell re. optimization. A
really nifty implementation of the scheme might use coroutines.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.