Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Compiler Optimisation? iain.bate@cs.york.ac.uk (Iain Bate) (1998-12-06) |
| Re: Compiler Optimisation? bear@sonic.net (Ray Dillinger) (1998-12-10) |
| Re: Compiler Optimisation? tc@charlie.cns.iit.edu (Thomas W. Christopher) (1998-12-10) |
| Re: Compiler Optimisation? silver@mail.webspan.net (Andy Gaynor) (1998-12-13) |
| Re: Compiler Optimisation? dewarr@my-dejanews.com (1998-12-13) |
| Re: Compiler Optimisation? albaugh@agames.com (1998-12-13) |
| Re: Compiler Optimisation? jfc@mit.edu (1998-12-13) |
| Re: Compiler Optimisation? monnier+comp/compilers/news/@tequila.cs.yale.edu (Stefan Monnier) (1998-12-18) |
| Re: Compiler Optimisation? bear@sonic.net (Ray Dillinger) (1998-12-18) |
| From: | Stefan Monnier <monnier+comp/compilers/news/@tequila.cs.yale.edu> |
| Newsgroups: | comp.lang.ada,comp.compilers |
| Date: | 18 Dec 1998 12:09:50 -0500 |
| Organization: | Compilers Central |
| References: | 98-12-010 98-12-016 98-12-024 |
| Keywords: | optimize |
>>>>> "dewarr" == dewarr <dewarr@my-dejanews.com> writes:
> This is misleading. Many compilers do MUCH more extensive
> peephole optimization. In particular gcc gets a FAR more
> significant improvement from peephole optimization.
This often reflects the fact that optimisations interact and that they
are often designed based on their interactions. In the SML/NJ example
mentioned by someone else, the `contraction' phase is relied upon by
many other optimisations (which end up just restructuring the code,
which in a first step makes it bigger and slower but exposes further
opportunities to the contraction phase).
Stefan
Return to the
comp.compilers page.
Search the
comp.compilers archives again.