Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!orca!paulsc
From: paulsc@orca.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Processing Instruction
Message-ID: <2344@orca.TEK.COM>
Date: Mon, 6-Apr-87 11:29:00 EST
Article-I.D.: orca.2344
Posted: Mon Apr  6 11:29:00 1987
Date-Received: Thu, 9-Apr-87 03:37:51 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15304@amdcad.UUCP> <15753@sun.uucp> <7843@utzoo.UUCP>
Reply-To: paulsc@orca.UUCP (Paul Scherf)
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 21
Keywords: instruction set architectures, Am29000
Xref: utgpu comp.arch:798 comp.lang.c:1496

In article <7843@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>> ... I think it is time for some *real* optimizing compilers that can detect
>> when they are compiling a benchmark and optimize for the appropriate 
>> instruction! :-) :-) :-)
>Don't laugh!  It's not unknown for an optimizing-compiler group to put extra
>attention into making common benchmarks run fast.  I'm told that there is at
>least one compiler that has a specialized loop-unrolling optimization whose
>major purpose is to quietly turn the "looping" version of Linpack into the
>"unrolled" version.

It isn't always a conscious effort to trick customers into
buying the compiler.  The compiler group might only have a
handful of "test programs" for their compiler.  If the compiler
does any peep hole optimizations, the compiler group probably
compiles whatever test programs they have to see how their
compiler might generate better code.  If any of their test
programs are benchmarks, they will be spending time making the
benchmarks run fast.

Paul Scherf, Tektronix, Box 1000, MS 61-033, Wilsonville, OR, USA
tektronix!orca!paulsc