B.2.131 -xprofile=p

Use this option to collect and save execution-frequency data so you can then use the data in subsequent runs to improve performance. This option is only valid when you specify optimization at level -xO2 or above.

You must specify -xprofile at compile time as well as link time. For a complete list of all compiler options that must be specified at both compile time and at link time, see Table A–2.

Compiling with high optimization levels (for example -xO5) is enhanced by providing the compiler with runtime-performance feedback. In order to produce runtime-performance feedback, you must compile with -xprofile=collect, run the executable against a typical data set, and then recompile at the highest optimization level and with -xprofile=use.

Profile collection is safe for multithreaded applications. That is, profiling a program that does its own multitasking ( -mt ) produces accurate results.

p must be collect[:name], use[:name], or tcov.

• collect[:name]

  Collects and saves execution-frequency data for later use by the optimizer with -xprofile=use. The compiler generates code to measure statement execution-frequency.

  ---

  Note –

  Do not specify -xprofile=collect when you build shared libraries on Linux.

  ---

  The name is the name of the program that is being analyzed. This name is optional. If name is not specified, a.out is assumed to be the name of the executable.

  You can set the environment variables SUN_PROFDATA and SUN_PROFDATA_DIR to control where a program compiled with -xprofile=collect stores the profile data. If set, the -xprofile=collect data is written to SUN_PROFDATA_DIR/SUN_PROFDATA.

  These environment variables similarly control the path and names of the profile data files written by tcov, as described in the tcov(1) man page.

  If these environment variables are not set, the profile data is written to name.profile/feedback in the current directory, where name is the name of the executable or the name specified in the -xprofile=collect:name flag. -xprofile does not append .profile to name if name already ends in .profile. If you run the program several times, the executions-frequency data accumulates in the feedback file; that is, output from prior executions is not lost.

  If you are compiling and linking in separate steps, make sure that any object files compiled with -xprofile=collect are also linked with -xprofile=collect.

• use[:name]

  The program is optimized by using the execution-frequency data generated and saved in the feedback files from a previous execution of the program that was compiled with– xprofile=collect.

  The name is the name of the program that is being analyzed. This name is optional. If name is not specified, a.out is assumed to be the name of the executable.

  Except for the -xprofile option which changes from -xprofile=collect to -xprofile=use, the source files and other compiler options must be exactly the same as those used for the compilation that created the compiled program which in turn generated the feedback file. The same version of the compiler must be used for both the collect build and the use build as well. If compiled with -xprofile=collect:name, the same program name name must appear in the optimizing compilation: -xprofile=use:name.

  The association between an object file and its profile data is based on the UNIX pathname of the object file when it is compiled with -xprofile=collect. In some circumstances, the compiler will not associate an object file with its profile data: the object file has no profile data because it was not previously compiled with -xprofile=collect, the object file is not linked in a program with -xprofile=collect, the program has never been executed.

  The compiler can also become confused if an object file was previously compiled in a different directory with -xprofile=collect and this object file shares a common basename with other object files compiled with -xprofile=collect but they cannot be uniquely identified by the names of their containing directories. In this case, even if the object file has profile data, the compiler will not be able to find it in the feedback directory when the object file is recompiled with -xprofile=use.

  All of these situations cause the compiler to lose the association between an object file and its profile data. Therefore, if an object file has profile data but the compiler is unable to associate it with the object file’s pathname when you specify -xprofile=use, use the -xprofile_pathmap option to identify correct directory. See B.2.133 -xprofile_pathmap.

• tcov

  Basic block coverage analysis using “new” style tcov.

  The -xprofile=tcov option is the new style of basic block profiling for tcov. It has similar functionality to the -xa option, but correctly collects data for programs that have source code in header files. See B.2.66 -xa for information on the old style of profiling, the tcov(1) man page, and Program Performance Analysis Tools for more details.

  Code instrumentation is performed similarly to that of the -xa option, but .d files are no longer generated. Instead, a single file is generated, the name of which is based on the final executable. For example, if the program is run out of /foo/bar/myprog.profile, the data file is stored in /foo/bar/myprog.profile/myprog.tcovd.

  The -xprofile=tcov and the -xa options are compatible in a single executable. That is, you can link a program that contains some files that have been compiled with -xprofile=tcov, and others with -xa. You cannot compile a single file with both options.

  When running tcov, you must pass it the -x option to make it use the new style of data. If not, tcov uses the old .d files, if any, by default for data, and produces unexpected output.

  Unlike the -xa option, the TCOVDIR environment variable has no effect at compile-time. However, its value is used at program runtime. See tcov(1) and Program Performance Analysis Tools for more details.

  ---

  Note –

  tcov’s code coverage report can be unreliable if there is inlining of routines due to -xO4 or -xinline.

  ---

When you use -xprofile=collect to compile a program for profile collection and -xprofile=use to compile a program for profile feedback, the source files and compiler options other than -xprofile=collect and -xprofile=use must be identical in both compilations.

The profile feedback directory names specified by the -xprofile=use:name option are accumulated from all instances of the option in a single invocation of the compiler. For example, assume that profile directories a.profile, b.profile and c.profile are created as a result of executing profiled binaries named a, b, and c respectively.

cc -O -c foo.c -xprofile=use:a -xprofile=use:b -xprofile=use:c
 

All three profile directories are used. Any valid profile feedback data pertaining to a particular object file is accumulated from the specified feedback directories when the object file is compiled.

If both -xprofile=collect and -xprofile=use are specified in the same command line, the rightmost -xprofile option in the command line is applied as follows:

• If the rightmost -xprofile option is -xprofile=use, all profile feedback directory names specified by the -xprofile=use options are used for feedback-directed optimization, and the previous -xprofile=collect options are ignored.

• If the right-most -xprofile option is -xprofile=collect, all profile feedback directory names specified by -xprofile=use options are ignored, and instrumentation for profile generation is enabled.

See also: -xhwcprof, -xprofile_ircache, -xprofile_pathmap