Compiling with high optimization levels (-xO5) is enhanced by providing the compiler with runtime performance feedback. To produce the profile feedback the compiler needs to do its best optimizations, you must compile first with -xprofile=collect, run the executable against a typical data set, and then recompile at the highest optimization level and with -xprofile=use.
See also the f95(1) man page for additional information about —xprofile and environment variables.
Collect and save execution frequency data for later use by the optimizer with -xprofile=use. The compiler generates code to measure statement execution frequency.
The name is the optional name of the directory in which profile data will be stored when the program is executed. If specified, name should be an absolute UNIX pathname. If name is not specified, profile data for a profiled program named program will be stored in a directory named program.profile in the current working directory at the time that program is executed.
At runtime a program compiled with -xprofile=collect:name will create by default the subdirectory name.profile to hold the runtime feedback information. The program writes its runtime profile data to the file named feedback in this subdirectory. If you run the program several times, the execution frequency data accumulates in the feedback file; that is, output from prior runs is not lost.
You can set the environment variables SUN_PROFDATA and SUN_PROFDATA_DIR to control the file and directory where a program compiled with -xprofile=collect writes its runtime profile data. With these variables set, the program compiled with -xprofile=collect writes its profile data 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.
Profile collection is “MT-safe”. That is, profiling a program that does its own multitasking by compiling with -mt and calling the multitasking library directly will give accurate results.
When compiling and linking in separate steps, the link step must also specify -xprofile=collect if it appears on the compile step.
Use execution frequency data to optimize strategically at optimization level -xO5.
As with collect:nm, the nm is optional and may be used to specify the name of the program.
The program is optimized by using the execution frequency data previously generated and saved in the profile data files written by a previous execution of the program compiled with -xprofile=collect.
The source files and other compiler options must be exactly the same as used for the compilation that created the compiled program that generated the feedback file. If compiled with -xprofile=collect:nm, the same program name nm must appear in the optimizing compilation: -xprofile=use:nm.
See also -xprofile_ircache for speeding up compilationg between the collect and use phases.
See also -xprofile_pathmap for controlling where the compiler looks for profile data files.
Code instrumentation is similar to that of -a, but .d files are no longer generated for each source file. Instead, a single file is generated, whose name is based on the name of the final executable. For example, if stuff is the executable file, then stuff.profile/tcovd is the data file.
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 -a, the TCOVDIR environment variable has no effect at compile–time. However, its value is used at program runtime to identify where to create the profile subdirectory.
See the tcov(1) man page, the “Performance Profiling” chapter of the Fortran Programming Guide, and the Program Performance Analysis Tools manual for more details.
The report produced by tcov can be unreliable if there is inlining of subprograms due to -O4 or -inline. Coverage of calls to routines that have been inlined is not recorded.