🚀 go-pugleaf

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

In article <160@bobkat.UUCP> m5@bobkat.UUCP (Mr Mike McNally) writes:
>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.
>
>
>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.

1) It certainly is possible to do the optimizations mentioned, although they
don't do you as much good in C as they do for FORTRAN or PASCAL.

2) Profiling feedback is usable.  The MIPSco compiler system has a
[not released, not counted in benchmarks, optional, etc] compiler
phase that can take profiling feedback files, then use the information for
selective inlining of procedures.  The feedback files get down to the
basic block, i.e., effective statment-by-statement counting.
"Selective inlining" means that you grab procedures inline only where they're
called frequently.  Besides eliminating function calls, this lets a serious
optimizer move newly-exposed-constant-subexpressions out of loops,
and eliminate newly-visible dead code. [Note that many arguments to functions
are constants, tests upon which can be eliminated at compile time.]
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086