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
cord(1) General Commands Manual cord(1)NAME
cord - Rearrange procedures in an executable file to facilitate better cache mapping
SYNOPSIS
cord [-vV] [-o outfile] [-f] [-c cachesize] [-p maxphases] obj-file reorder-file
OPTIONS
The cord command accepts the following options: Prints verbose information. This includes listing those procedures that are considered part
of other procedures and that cannot be rearranged (that is, assembler procedures that may contain relative branches to other procedures
instead of relocatable branches). The listing also lists those procedures in the flipped area (if any) and a mapping of old location to
new. Displays the version of the cord command. Specifies the output file. If not specified, a.out is used. Flips the first cachepage
size procedures. When cord was written, the assumption was that procedures would be reordered by procedure density (cycles/byte). This
option ensures that the densest part of each page following the first cachepage would conflict with the least-dense part of the first
cachepage. Specifies the cache size (in bytes) of the machine on which you want to execute. This only affects the -f option. If not speci-
fied, 65536 is used. Specifies the maximum number phases allowed. The default is 20.
DESCRIPTION
The cord command rearranges procedures in an executable object file to maximize efficiency in a machine's cache. By rearranging the proce-
dures properly, you can reduce the instruction cache miss rates. The cord command does not attempt to determine the correct ordering; it
must be given a reorder-file containing the desired procedure order. The reorder file is generated by the ftoc program, which in turn gen-
erates a reorder file from a set of profile feedback files (see prof(1)).
Processed lines in the reorder file are called procedure lines. Each procedure line must be on a separate source line. Each procedure line
must contain the source name of the file, followed by a blank, followed by a qualified procedure name. Nested procedures must be qualified
x.y, where x is the outer procedure. A newline or blank can follow the procedure name:
foo.c bar (everything else following is ignored)
Lines beginning with # are comments, lines beginning with $ are considered cord directive lines. The only directive currently understood is
$phase. This directive will consider the rest of the file (until the end of file or next $phase) as a new phase of the program and will
order the procedures accordingly. A procedure may appear in more than one phase, resulting in more than one copy of it in the final
binary. First, cord will try to relocate procedure references to a copy of the procedure belonging to the requesting phase; otherwise, it
will relocate the references to a random copy.
Use the -cord option to a compiler driver like cc(1) rather than execute cord directly. The cord options can be specified with -Wc,cor-
darg0,cordarg1,.... If you have to run cord by hand, you may want to run it once with the driver using the -v option on a simple program.
This will enable you to see the exact passes and the arguments involved in using cord.
Warning
Since cord works from an input list of procedures generated from profile output, the resulting binary is data dependent. In other words, it
may only perform well on the same input data that generated the profile information, and may perform worse than the original binary on
other data. Furthermore, if the hot areas in the cache do not fit well into one cachepage, performance can degrade.
SEE ALSO
Commands: cc(1), ftoc(1), ld(1), prof(1)
Programmer's Guide
cord(1)