Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site smu
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!smu!mike
From: mike@smu
Newsgroups: net.micro.mac
Subject: Re: slow C compilers
Message-ID: <20800041@smu>
Date: Mon, 16-Sep-85 14:06:00 EDT
Article-I.D.: smu.20800041
Posted: Mon Sep 16 14:06:00 1985
Date-Received: Sun, 29-Sep-85 04:48:39 EDT
References: <417@decwrl.UUCP>
Lines: 21
Nf-ID: #R:decwrl.UUCP:-41700:smu:20800041:000:1001
Nf-From: smu!mike    Sep 16 13:06:00 1985


There's sort of a problem with the idea of an extensiveley optimizing
C compiler.  First, some of the optimizations mentioned (code
hoisting, common subexpression elimination (I suppose beyond basic
blocks), and various loop optimizations) take a lot of space (in
general).  Maybe you're willing to pay this price.  The other (and
real) problem is that C, because of its low-level (I don't really like
that term) nature, is not supposed to be thusly optimized.
Check pages 49 and 50 of K&R.  

I suppose I would sort of lke an optimizing compiler as well, but I've
gotten pretty good at writing the source code efficiently to begin
with (some would say this is a bad habit, but most of my life is
pretty sleazy anyway so this doesn't bother me).  I remember a
possibly apocryphal story I heard in a compiler class about a guy who
wrote a FORTRAN source code optimizer that was more effective than
IBM's FORTRAN G (or maybe H, whichever is the good one).

Mike McNally		SMU
mike@smu
...convex!smu!mike