Path: utzoo!utgpu!water!watmath!clyde!rutgers!bellcore!faline!hammond
From: hammond@faline.bellcore.com (Rich A. Hammond)
Newsgroups: comp.arch
Subject: Re: FREQUENCY statements: fill a much-needed gap
Message-ID: <1722@faline.bellcore.com>
Date: 20 Jan 88 13:34:13 GMT
References: <839@ima.ISC.COM> <28200085@ccvaxa> <1267@winchester.UUCP> <2861@clash.rutgers.edu>
Reply-To: hammond@faline.UUCP (Rich A. Hammond)
Organization: Bellcore MRE
Lines: 30

One case that I would like to see the programmer comment for the
compiler and other readers is error recovery routines.  Quite
often the routines lack names that I immediately recognize as
error handling and the compiler has no way of knowing whether "perror"
is really the libc routine or a function declared by the programmer.

In this case the programmer could be relatively certain of the
frequency (or alternatively doesn't care if the error recovery is
slower) and the compiler could put code, such as save all the registers
before the error routine calls,  that would enable better code for the
case that we wish to go quickly.

This is somewhat different from commenting all branches and should be
helpful to both future code maintainers and the compiler and doesn't
depend on tracing to get useful results.

The problem that I have with using trace information is its effect
on benchmarks.  Optimizing a program for a given set of inputs will
make benchmarks run wonderfully, but may not reflect the case we
really want to measure.  Averaging the run time of the benchmark
with trace information and without might give us a better feel,
but we'd force a more complex compiler, since I assume it would
use two different branch prediction strategies, both with possible
bugs.

This isn't to say that we shouldn't use tracing, just that benchmarks
should indicate exactly what the compiler options and their effects
were.

Rich Hammond