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

allegra!utzoo!henry
Wed, 22 Apr 87 03:03:43 EDT

          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: Wed, 22 Apr 87 03:03:43 EDT
From: allegra!utzoo!henry
References: <1299@ames.UUCP>

> ... Another approach that
> I have seen is to run the source program through a preprocessor which adds
> tracing code into the source, then compile the resulting program with the
> regular compiler.


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 suggest "before" rather than "after" because then the condition codes
don't get messed up, or at least not as badly -- beware optimizing
compilers rearranging code!)


If you did it at the assembler level rather than the binary level, this
might not be too hard. That might be awkward if libraries are involved,
though.


This gets you fast, accurate counts without compiler cooperation.


Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
--


Post a followup to this message

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