Below are some notes on feedback in the SGI Pro64 compiler.
How To Use Feedback
-------------------
Using feedback is a three step process:
(1) Compile the source with intrumentation turned on, producing a binary;
(2) Execute the binary on sample input, generating a file of feedback data;
(3) Recompile the source with annotation turned on.
Feedback instrumentation uses the libinstr.so library.
Suppose you want to run frequency for the program test.c, and you want to
store the data in a file fbdata. (Usually, I use the same name for the
feedback data file and the program, so fbdata would be test.)
First, compile test.c with instrumentation on. "<path>" is the path to
libinstr.so
sgicc -fb_create fbdata -L<path> -linstr test.c
Second, execute the compiled program on the sample input data. The
instrumented program will run significantly slower than usual.
./a.out
This will create a file of frequency data, named "fbpath.instr0.######".
The 0 in "instr0" indicates that instrumentation occurred before VHO
lowering. (Eventually, it should be possible to instrument at a variety
of stages.) You can perform multiple runs using different input data
to generate multiple frequency data files.
Third, recompile test.c using the feedback data. Feedback data will be
read and combined from all files with names "fbpath.instr0.######".
(So, you need to delete obsolete feedback data files or use a different
feedback file name.)
$TOOLROOT/usr/bin/cc -fb_opt fbdata test.c
Any flags that affect compilation should be the same as during the first,
instumentation compilation.
What Feedback Does
------------------
Feedback collects frequency counts on control flow related whirl
instructions, such as branches, loops, and procedure calls. Memory
accesses are not counted.
During the instrumentation step, the compiler inserts extra code into
the whirl representation. The insterted code consists of procedure calls
to libinstr.so routines which gather control flow data, such has the
number of times a branch is taken or not taken, how many times a loop
iterates, and how many times procedures are invoked.
When the instrumented binary is invoked on the test data, the program
performs as normal, except that the libinstr.so routines collect control
flow frequencies and store the counts into a file when the program
completes.
During the annotation step, the compiler reads the frequency data from
any available feedback data files and "attaches" the data to the whirl
nodes. Annotation occurs at the same point of compilation that
instrumentation occured (warly in the backend, just before VHO lowering).
In fact, the wrirl representation look the same as it did during the
instrumentation step, so the same compiler flags should be used.
Later phases of the compiler (particular IPA and CG) then can use the
data to guide optimization decisions. Compiler optimizations that
transform the whirl control flow structure also invoke procedures that
update the frequency counts, sometimes making educated guesses when the
exact counts cannot be determined.
Trace Flags
-----------
If you want to see the frequency counts during the second compilation,
use the flags:
-Wb,-tt16:0x1111
This will cause frequency data to be dumped to the trace file test.t.
For debugging purposes, inconsistancies in the feedback data are also
identified in the trace file. Other tracing flags are defined in
be/com/fb_whirl.h
Internally, frequency values are stored as 64-bit FB_FREQ data types,
which can have one of the following values:
--> an EXACT nonnegative 32-bit float value
--> a GUESS nonnegative 32-bit float value
--> UNKNOWN
--> UNINIT
--> ERROR
EXACT values give a precise count of the number of times that a
particular cfg edge was traveled during the program's instrumentated
executions. GUESS values are educated estimates of the count. GUESS
and UNKNOWN values can be introduced when the compiler transforms the
controlflow of the whirl representation. The symbols "!" and "?" are
used to distinguish between EXACT and GUESS frequencies in trace files.
One Warning
-----------
Feedback is significantly less finished and tested than the rest of
the compiler.
|