Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

pixie(1) [ultrix man page]

pixie(1)						      General Commands Manual							  pixie(1)

Name
       pixie - add profiling code to a program

Syntax
       pixie in_prog_name [ options ]

Description
       The pixie command reads an executable program, partitions it into basic blocks, and writes an equivalent program containing additional code
       that counts the execution of each basic block. A basic block is a region of the program that can be  entered  only  at  the  beginning  and
       exited only at the end.	The pixie command also generates a file containing the address of each of the basic blocks.

       When  you run the pixie-generated program, it (provided it terminates normally or via a call to generates a file containing the basic block
       counts. The name of the file is that of the original program with any leading directory names removed and ".Counts" appended.  and can ana-
       lyze these files and produce a listing of profiling data.

Options
       -o out_prog_name    Specify  a  name  for  the translation.  The default is to remove any leading directory names from the in_prog_name and
			   append ".pixie".

       -bbaddrs name	   Specify a name for the file of basic block addresses.  Default is to  remove  any  leading  directory  names  from  the
			   in_prog_name and append ".Addrs".

       -[no]quiet	   Controls whether a summary is given of the binary-to-binary translation process. The default is -noquiet.

       -[no]dwops	   Controls translation of double-word load/store instructions so that binaries using these instructions can be run on old
			   processors.	The default is -nodwops (translate).

       -[no]textdata	   Controls whether pixie puts the original text into the translated output.  This is required to correctly translate pro-
			   grams  with	data  in  the text section (for example, f77 format statements in some compiler releases).  The default is
			   -textdata (include original text).

       -[no]idtrace	   Disables or enables tracing of instruction and data memory references.  -idtrace is equivalent to  using  both  -itrace
			   and -dtrace together.  The default is -noidtrace

       -[no]itrace	   Disable or enable tracing of instruction memory references.	The default is -noitrace

       -[no]dtrace	   Disable or enable tracing of data memory references.  Currently, -dtrace requires -itrace.  The default is -nodtrace

       -[no]oldtrace	   Disable or enable the old memory reference trace format.  The default is -oldtrace.

       -idtrace_sample number
			   Record only 1 out of every number memory reference chunks. (This feature not yet implemented.)

       -idtrace_file number
			   Specify a UNIX file descriptor number for the trace output file.  The default is 19.

Restrictions
       The handler function address to the signal system calls is not translated, therefore, programs that receive signals  cannot work pixified.

       Programs  that  call vfork cannot work pixified because the child process modifies the parent state required for pixie operation.  Use fork
       instead.

       Pixified code is substantially larger than the original code.  Conditional branches that used to fit  in  the  16-bit  branch  displacement
       field may no longer fit, generating a pixie error.

See Also
       prof(1), pixstats(1)

4th Berkeley Distribution					       RISC								  pixie(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)
Man Page