Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!caip!clyde!cuae2!ltuxa!we53!sw013b!dj3b1!killer!ndmce!pollux!bobkat!m5
From: m5@bobkat.UUCP (Mr Mike McNally)
Newsgroups: net.lang.c
Subject: Re: Optimizing C Compiler Sought
Message-ID: <160@bobkat.UUCP>
Date: Mon, 13-Oct-86 09:08:49 EDT
Article-I.D.: bobkat.160
Posted: Mon Oct 13 09:08:49 1986
Date-Received: Fri, 17-Oct-86 03:35:45 EDT
References: <4467@brl-smoke.ARPA>
Reply-To: m5@bobkat.UUCP (Mr Mike McNally)
Organization: Digital Lynx; Dallas, TX
Lines: 39

In article <4467@brl-smoke.ARPA> NET-RELAY.ARPA>@brl-smoke.ARPA writes:
>Does anyone know of a C compiler that will use its own profiling output
>to generate faster runtime code?  I've long thought that a compiler that
>didn't accept data about the runtime behavior of a program shouldn't
>call itself a execution-time optimizing compiler - space maybe but not time.
>
>					Thanks, Scott
>
>"In an evolving man-machine system, the man will get dumber faster than 
>the machine gets smarter."

A long time ago a professor told me about a compiler that somebody had
written for a WCS lsi-11 (I think it was an 11/05).  The compiler would
use profiling information to decide which chunks of generated code needed
to be compressed into a single, newly (and automatically) microcoded
instruction.  I always thought that this was nifty, although it seemed
to me that upgrading to a faster processor would have been simpler :-)

In the case of optimizing C, there are various well-discussed semantic
characteristics of the language which prevent all but the most local
optimizations (I personally have never been convinced that this is 
always a ``feature'').  Even if it were possible to do local or global
common subexpression elimination, loop unravelling, induction variable
elimination, etc., I think that allowing the compiler to optimize 
anything it can will result in good code.  Useful profile information
might be somewhat difficult to generate, given a program with several
possible flow characteristics and large possible input sets.  The only
use of such information would be to make space/time tradeoff decisions,
and these probably are more easily done through some sort of ``pragma''
construct.

-- 
****                                                         ****
**** At Digital Lynx, we're almost in Garland, but not quite ****
****                                                         ****

Mike McNally                                    Digital Lynx Inc.
Software (not hardware) Person                  Dallas  TX  75243
uucp: ...convex!ctvax!bobkat!m5                 (214) 238-7474