ftoc(1) General Commands Manual ftoc(1)
NAME
ftoc - interface between prof and cord
SYNOPSIS
ftoc file1...
DESCRIPTION
The ftoc interface reads one or more feedback files produced by the -feedback option of the profiler prof(1) and writes onto stdout a
reorder-file for use with the cache-rearranging program cord(1). It interprets each feedback file as representing one phase of a program's
execution. In other words, if a program behaves in two distinct ways depending on its input, you could create two different feedback files
by executing the program twice with different input data, and both ftoc and cord will understand that the information from the first file
is distinct from that of the second file.
As an example, to improve the instruction-cache performance of a program called hello, you could generate a new hello.cord program by say-
ing:
cc -o hello hello.c pixie -o hello.pixie hello hello.pixie prof -pixie -feedback hello.feedback hello ftoc hello.feedback > hello.reorder
cord -o hello.cord hello hello.reorder
The reorderfile consists of a list of lines of the form:
sourcefile procname.procname... n
where "procname.procname..." represents an outer-to-inner list of nested procedures, and n is 10 times the percentage of the procedure's
"density" with respect to the total of the densities of all procedures. ("Density" is the ratio of a procedure's total cycles to its total
static instructions.) A line consisting of "$phase" separates information from different feedback files.
SEE ALSO
cord(1), pixie(1), prof(1)
ftoc(1)
Check Out this Related Man Page
spike(1) General Commands Manual spike(1)
NAME
spike - Performs code optimization after linking a program
SYNOPSIS
spike binary_file [options...]
OPTIONS
Names the optimized binary output file. The default file name is a.out. Causes spike to use the feedback database stored in file, where
file is the name of the input executable. This database is created by first compiling the program with the -feedback option (for example,
cc -feedback prog) and then instrumenting and running the program with the pixie -update or prof -pixie -update command (see cc(1),
pixie(1), and prof(1)). Causes spike to use file.Addrs (basic block addresses file) and file.Counts (basic block counts file) for profile-
based optimization. These files are produced by the pixie tool (see pixie(1) and prof(1)). spike can be applied only to V5.1 or later
kernels. Use this option when applying spike to the UNIX kernel (vmunix). Disables code layout optimization that splits procedures into
multiple parts. Disables basic block chaining, which arranges code so that the fall through path is the commonly taken path. Disables
procedure ordering. Reduces the number of padding nops inserted into the code to align instructions. The alignment usually makes the code
run faster, but makes the code larger, which can cause more instruction cache misses. Adjusts the threshold used by procedure splitting in
code layout to decide which code is frequently and infrequently executed. The default is that make up at least 99 percent of the estimated
execution time are considered frequently executed and the rest are marked as infrequently executed. Increasing the threshold can help when
the profile is not representative. For example, try a value of Displays the version number of spike.
OPERANDS
Name of the binary file to which spike is to be applied.
DESCRIPTION
spike is a tool for performing code optimization after linking. It is a replacement for om and does similar optimizations. Because it can
operate on an entire program, spike is able to do optimizations that cannot be done by the compiler.
Some of the optimizations that spike performs are code layout, deleting unreachable code, and optimization of address computations. spike
is most effective when it uses profile information to guide optimization.
spike can process binaries linked on Tru64 UNIX (formerly Digital UNIX) Version 4.0 or later systems. Binaries that are linked on Version
5.1 or later systems contain information that allows spike to do additional optimization.
You can use spike in two ways: By applying the spike command to a binary file after compilation. As part of the compilation process, by
specifying the -spike option with the cc command (or the cxx, f77, or f90 command, if the associated compiler is installed).
The -spike option is more convenient when you are not using profile information (Example 2), or you are using profile information in the
compiler, too (Example 3). The spike command is more convenient if you do not want to relink the executable (Example 1) or you are using
profile information after compilation (Examples 4 and 5).
All spike command options can be passed directly to the cc command's -spike option by using the (cc) -WS option. Example 6 shows the syn-
tax.
RESTRICTIONS
spike cannot process images that have been stripped. contain RPDR tables (see Section 2.3.7, Special Symbols, of the Object File/Symbol
Table Format Specification) compute an offset from a code address. modify the text section at runtime.
Using cord, atom, pixie, hiprof, or third on an image that has been processed with spike is unsupported.
NOTES
spike tries to update the symbol table in the binary so that the optimized binary can be debugged. As with other compiler optimizations,
there may be some situations where the debugger may not be able to properly report the current location in the program or display the val-
ues of variables. If spike divides a procedure into multiple disjoint parts, the main body will keep the original procedure name, but the
other parts will have names that are the original name with _cold_n (where n is a number) appended to the end.
EXAMPLES
In the following example, spike is applied to the binary my_prog, producing the optimized output file prog1.opt. % spike my_prog -o
prog1.opt In the following example, spike is applied during compilation with the cc command's -spike option: % cc -c file1.c % cc -o prog3
file1.o -spike
The first command line creates the object file file1.o. The second command line links file1.o into an executable and uses spike to
optimize the executable. The following example shows how to optimize a program, prog, by first compiling it with the -feedback
option, then merging profiling statistics from two instrumented runs of the program, then compiling it with the -spike and -feedback
options so the feedback information stored in the executable is used by the compiler and spike: % cc -feedback prog -o prog *.c %
pixie -pids prog % prog.pixie (input set 1) % prog.pixie (input set 2) % prof -pixie -update prog prog.Counts.* % cc -spike -feed-
back prog -o prog *.c
The first compilation produces an augmented executable that will later accept feedback information.
The pixie command creates an instrumented program (prog.pixie), which is then run twice. The -pids option adds the process ID of
each test run to the name of the profiling data file produced -- for example prog.Counts.371 and prog.Counts.422.
The prof -pixie command merges the two data files. The -update option updates the executable, prog, with the combined information.
The program is compiled with the -spike and -feedback options so the feedback information stored in the executable is used by the
compiler and spike. The following example shows how to optimize a program, prog, by first compiling it with the -feedback option,
then merging profiling statistics from two instrumented runs of the program, then applying the spike -feedback command to use the
feedback information stored in the executable: % cc -feedback prog -o prog *.c % pixie -pids prog % prog.pixie (input set 1) %
prog.pixie (input set 2) % prof -pixie -update prog prog.Counts.* % spike prog -feedback prog -o prog.opt
As in the previous example, the first compilation produces an augmented executable. The instrumented program is run twice, producing
a uniquely named data file each time. The prof -pixie -update command merges the two data files and updates the executable with the
combined information.
The spike -feedback command uses the combined profiling information to produce the optimized output file prog.opt. The following
example shows how to optimize a program, prog, by merging profiling statistics from two instrumented runs of the program, then
applying the spike -fb command to use the feedback information in the and files: % cc prog -o prog *.c % pixie -pids prog %
prog.pixie (input set 1) % prog.pixie (input set 2) % prof -pixie -merge prog.Counts prog prog.Addrs prog.Counts.* % spike prog -fb
prog -o prog.opt
The first compilation produces a normal executable. As in the previous example, the instrumented program is run twice, producing a
uniquely named data file each time.
The prof -pixie -merge command merges the two data files into one combined prog.Counts file.
The spike -fb command uses the information in prog.Addrs and prog.Counts to produce the optimized output file prog.opt.
The method in Example 4 is preferred. You should use the method in Example 5 only if you cannot compile with the -feedback option
that uses feedback information stored in the executable. The following example shows the syntax for passing spike command options
to the (cc) -spike option by using the (cc) -WS option: % cc -spike -feedback prog -o prog *.c
-WS,-splitThresh,.999,-noaggressiveAlign
RETURN STATUS
spike returns the following status values:
0: Success
Nonzero: Error
SEE ALSO
cc(1), pixie(1), prof(1)
Programmer's Guide
spike(1)