Re: Static analysis of code for "flop counting"?

think!ames!ucbcad!ucbvax!decwrl!mips!sjc (Steve Correll)
Thu, 23 Apr 87 20:12:13 PST

          From comp.compilers

Related articles
Static analysis of code for "flop counting"? fouts@orville (1987-04-17)
Re: Static analysis of code for "flop counting"? allegra!utzoo!henry (1987-04-22)
Re: Static analysis of code for "flop counting"? think!ames!ucbcad!ucbvax!decwrl!mips!sjc (1987-04-23)
Re: Static analysis of code for "flop counting"? harvard!seismo!watmath!orchid!atbowler (Alan T. Bowler [SDG]) (1987-04-26)
Re: Static analysis of code for "flop counting"? eugene@ames-pioneer.arpa (Eugene Miya N.) (1987-05-06)
Re: Static analysis of code for "flop counting"? eugene@ames-pioneer.arpa (Eugene Miya N.) (1987-05-06)
Re: Static analysis of code for "flop counting"? allegra!utzoo!henry (1987-05-13)
| List of all articles for this month |
Date: Thu, 23 Apr 87 20:12:13 PST
From: think!ames!ucbcad!ucbvax!decwrl!mips!sjc (Steve Correll)

> 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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.