HP UX Software Transition Kit (STK) manual Using The flow.data File

Notice how the program is now linked with /usr/ccs/lib/crt0.o instead of /opt/langtools/lib/icrt0.o because the profiling code is no longer needed.

Using The flow.data File

By default, the code generator and linker look for the flow.data file in the current working directory. In other words, the flow.data file created during the profiling phase should be located in the directory where you relink the program.

Specifying a Different flow.data File with +df

What if you want to use a flow.data file from a different directory than where you are linking? Or what if you have renamed the flow.data file - for example, if you have multiple flow.data files created for different input sets? The +df option allows you to override the default +P behavior of using the file flow.data in the current directory. The compiler passes this option directly to the linker.

For example, suppose after collecting profile data, you decide to rename flow.data to prog.prf. You could then use the +df option as follows:

$ cc -v -o prog +P +df prog.prf prog.o

/usr/ccs/bin/ld /usr/ccs/lib/crt0.o -u main -o prog \ +df prog.prf prog.o -P -lc

The +df option overrides the effects of the FLOW_DATA environment variable.

Specifying a Different flow.data with FLOW_DATA

The FLOW_DATA environment variable provides another way to override the default flow.data file name and location. If set, this variable defines an alternate file name for the profile data file. For example, to use the file /home/adam/projX/prog.data instead of flow.data, set FLOW_DATA:

$ FLOW_DATA=/home/adam/projX/prog.data

$ export	FLOW_DATA		Bourne and Korn shell
$ setenv	FLOW_DATA	/home/adam/projX/prog.data	C shell

Interaction between FLOW_DATA and +df

If an application is linked with +df and -P, the FLOW_DATA environment variable is ignored. In other words, +df overrides the effects of FLOW_DATA.

Specifying a Different Program Name (+pgm)

When retrieving a program's profile data from the flow.data file, the linker uses the program's basename as a lookup key. For instance, if a program were compiled as follows, the linker would look for the profile data under the name foobar:

$ cc -v -o foobar +P foo.o bar.o

/usr/ccs/bin/ld /usr/ccs/lib/crt0.o -u main -o foobar \ foo.o bar.o -P -lc

This works fine as long as the name of the program is the same during the instrumentation and optimization phases. But what if the name of the instrumented program is not the same as name of the final optimized program? What does linker do?

Let us say, for example, you want the name of the instrumented application to be different from the optimized application. So, you use the following compiler commands

$ cc -O +I -o		prog.inst prog.c	//Instrument prog.inst.
$ prog.inst	<	input_file1	//Profile it, storing the data under
			the name prog.inst.
$ prog.inst	<	input_file2

Linker Optimizations 211