When it starts up, LoopReport expects to be given the name of your program. Type loopreport and the name of the program (an executable) you want examined.
% loopreport program
You can also start LoopReport with no file specified. However, if you invoke LoopReport without giving it the name of a program, it looks for a file named a.out in the current working directory.
% loopreport > a.out.loopreport
You can also direct the output into a file, or pipe it into another command:
% loopreport program > program.loopreport % loopreport program | more
LoopReport also reads the timing file associated with your program. The timing file is created when you use the -zlp option, and contains information about loops. Typically, this file has a name of the format program.looptimes, and is found in the same directory as your program.
However, there are four ways to specify the location of a timing file. LoopReport chooses a timing file according to the rules listed below.
If a timing file is named on the command line, LoopReport uses that file.
% loopreport program newtimes > program.loopreport
If the command-line option -p is used, LoopReport looks in the directory named by -p for a timing file.
% loopreport program -p /home/timingfiles > program.loopreport
If the environment variable LVPATH is set, LoopReport looks in that directory for a timing file.
% setenv LVPATH /home/timingfiles % loopreport program > program.loopreport
LoopReport writes the table of loop statistics to stdout--the standard output. You can also redirect the output to a file, or pipe it into another command:
% loopreport program > program.loopreport % loopreport program | more
The descriptions below apply equally to LoopTool's "Create Report" output and LoopReport's output.
The loop report contains the following information:
LoopID
An arbitrary number, assigned by the compiler during compile time. This is just an internal loopID, useful for talking about loops, but not really related in any way to your program.
Line #
The line number of the first statement of the loop in the source file.
Par?
Par is short for "Parallelized by the compiler?" Y means that this loop was marked for parallelization; N means that the loop was not.
Hints
Number corresponding to hint text in the "Legend for compiler hints" list.
Entries
Number of times this loop was entered from above. This is distinct from the number of loop iterations, which is the total number of times a loop executes. For example, these are two loops in Fortran.
do 10 i=1,17 do 10 j=1,50 ...some code... 10 continue
The first loop is entered once, and it iterates 17 times. The second loop is entered 17 times, and it iterates 17*50 = 850 times.
Nest
Nesting level of the loop. If a loop is a top-level loop, its nesting level is 0. If the loop is the child of another loop, its nesting level is 1.
For example, in this C code, the i loop has a nesting level of 0, the j loop has a nesting level of 1, and the k loop has a nesting level of 2.
for (i=0; i<17; i++) for (j=0; j<42; j++) for (k=0; k<1000; k++) do something;
Wallclock
The total amount of elapsed wallclock time spent executing this loop for the whole program. The elapsed time for an outer loop includes the elapsed time for an inner loop. For example:
for (i=1; i<10; i++) for (j=1; j<10; j++) do something;
The time assigned to the outer loop (the i loop) might be 10 seconds, and the time assigned to the inner loop (the j loop) might be 9.9 seconds.
Percentage
The percentage of total program runtime measured as wallclock time spent executing this loop. As with wallclock time, outer loops are credited with time spent in loops they contain.
Variables
The names of the variables that cause a data dependency in this loop. This field only appears when the compiler hint indicates that this loop suffers from a data dependency. A data dependency occurs when parallelization of a loop can not be done safely because the values computed in one iteration of a loop are used in another. The following illustrates a data dependency:
do i = 1, N a(i) = b(i) + c(i) b(i) = 2 * a(i + 1) end do
If the example loop above is run in parallel, iteration 1 which recomputes b(1) based on the value of a(2), may run after iteration 2 which has recomputed a(2). The value of b(1) is determined by the new value of a(2) rather than the original value as would happen if the loop is not parallelized.