Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!johnl
From: johnl@ima.UUCP
Newsgroups: comp.compilers
Subject: Re: Static analysis of code for "flop counting"?
Message-ID: <556@ima.UUCP>
Date: Thu, 23-Apr-87 23:12:13 EST
Article-I.D.: ima.556
Posted: Thu Apr 23 23:12:13 1987
Date-Received: Sat, 25-Apr-87 12:02:24 EST
Sender: johnl@ima.UUCP
Lines: 41
Approved: compilers@ima.UUCP

> Yet another approach, used (although not for this purpose, I suspect) by
> the MIPSCo people, is to run the object program through a postprocessor
> that inserts tracing code.  For example, before every "add float"
> instruction, insert an instruction that bumps an "add float" counter.

I'll elaborate a bit:  As Henry said, our postprocessor "pixie" does
indeed work on the already-linked program (Unix a.out format) rather than
on assembly code, so that libraries get included automatically, which is
fortunate, because neglecting libraries sometimes makes a big difference
(whetstone, for example).

"pixie" actually inserts the counting-code at the beginning of each basic
block, rather than before particular instructions of interest.  It
identifies basic blocks the hard way, by passing through the program
once to collect all of the branch-, jump-, and call-targets.  And it
remaps the registers onto a smaller set, spilling into memory as
necessary, so that certain registers are globally available for use by
the counting-code.  Dynamic branches (e.g. case statements) get handled
laboriously at execution time.

The extra difficulty of identifying basic blocks pays off by reducing
the time spent in the counting-code (often a single basic block
contains multiple instances of whatever we want to count), and by
making the system more versatile. A second postprocessor examines the
counts and basic-block boundaries provided by the first, plus the
original linked program, and derives statistics on whatever aspect of
the program we're interested in (cycles, ratio of loads to stores,
ratio of byte operations to word operations, etc).  We can measure new
things by changing the second postprocessor, without changing "pixie".

It's a lovely tool (written by a fellow named Earl Killian). If you just
want to count flops, however, then editing the assembly file to preface
each floating-point op with a call to a counting subroutine will solve
your problem.

...decwrl!mips!sjc						Steve Correll
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request