Re: Smallest Optimizer

Geoff Langdale <>
Mon, 27 Feb 1995 17:53:13 GMT

          From comp.compilers

Related articles
Smallest Optimizer (1995-02-18)
Re: Smallest Optimizer (1995-02-21)
Re: Smallest Optimizer (1995-02-24)
Re: Smallest Optimizer (1995-02-27)
Re: Smallest Optimizer (Geoff Langdale) (1995-02-27)
Re: Smallest Optimizer (Dave Lloyd) (1995-03-04)
Re: Smallest Optimizer (Dave Lloyd) (1995-03-11)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Geoff Langdale <>
Keywords: optimize
Organization: Carnegie Mellon University
References: 95-02-144 95-02-185
Date: Mon, 27 Feb 1995 17:53:13 GMT
Return-Path: <news@CANTALOUPE.SRV.CS.CMU.EDU> (Smail3.1.28.1 #3) id m0rj9bn-0005x2C; Mon, 27 Feb 95 12:51 EST

In article 95-02-185, (Preston Briggs) writes:
|> I always liked optimizers that were thorough and asymptotically fast
|> (or at least not asymptotically slow!). In recent articles, people
|> have claimed that certain optimizations don't pay off enough to be
|> worth implementing, or perhaps implementing well. Maybe so. Vicky
|> Markstein, when she was part of the compiler crew at IBM Yorktown,
|> suggested including an optimization only if the net effect was to
|> speed up the compiler (when compiled with itself).

I am told that this was true of the first C compiler: new features
added to the C language increased the size of the compiler source, and
memory was tight on the (I think) PDP-11/20, so language features were
only added when they caused the compiler with these new features, when
compiled with itself, to be no larger than the compiler without the
features. I'm not sure how long this constraint on C development
lasted, but it certainly sounds like a good way to keep things lean.

Imagine this limit having been applied to ML, or suchlike. :-)

Geoff Langdale
Grad Student
Carnegie Mellon University


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.