|Register optimizations ArielMars@aol.com (1995-03-02)|
|Re: Register optimizations email@example.com (1995-03-05)|
|Re: Register optimizations firstname.lastname@example.org (1995-03-08)|
|Re: Register optimizations email@example.com (1995-03-09)|
|Re: Register optimizations firstname.lastname@example.org (1995-03-12)|
|Re: Register optimizations email@example.com (1995-03-16)|
|Re: Register optimizations firstname.lastname@example.org.OZ.AU (1995-03-18)|
|optimizing compiler design email@example.com (1995-03-21)|
|From:||firstname.lastname@example.org.OZ.AU (Thomas Charles CONWAY)|
|Organization:||Computer Science, University of Melbourne, Australia|
|Date:||Sat, 18 Mar 1995 01:43:28 GMT|
email@example.com (Preston Briggs) writes:
>The front end should be resolutely non-optimizing.
Why should this be the case? The compiler that my research group
is writing optimizes a few things (so far) at the high level,
and we have a few honours students just starting with us who will
be looking at high level optimization which will take place in the
front end of the compiler.
It is true that to date, the majority of optimization has been done
on low-level intermediate code, and such optimization can be very
effective, but there are fewer and fewer new oppertunities for such
optimization, so if you want your compiler to be better than the
rest, then you need to seek new horizons. This is where language
design (rather than language implementation) becomes very important:
if your language can specify a minimum of "how" information (eg
sequencing, variable update, etc), and a maximum of "what" information
(eg x depends on *these* variables, to evaluate z we first need to
evaluate these three functions, etc), then hopefully the compiler
will be able to manipulate the high level form of the program to
improve its behaviour at the algorithmic level.
Such optimizations already exist: deforrestation (Wadler),
constraint propegation (eg Tsutsumi, et al), and so on.
Return to the
Search the comp.compilers archives again.