Interprocedural Optimizations (IPO) Report

The IPO report provides information on the functions that have been inlined and can help to identify the problem loops. The report can help to identify how and where the compiler applied IPO to the source files.

The following command examples demonstrate how to run the IPO reports with the minimum output.

Operating System

Syntax Examples

Linux* and Mac OS* X

 icc -opt-report 1 -opt-report-phase=ipo a.cpp b.cpp

Windows*

 icl /Qopt-report:1 /Qopt-report-phase:ipo a.cpp b.cpp

where -opt-report (Linux and Mac OS X) or /Qopt-report (Windows) invokes the report generator, and -opt-report-phase=ipo (Linux and Mac OS X) or /Qopt-report-phase:ipo (Windows) indicates the phase (ipo) to report.

You can use -opt-report-file (Linux and Mac OS X) or /Qopt-report-file (Windows) to specify an output file to capture the report results. Specifying a file to capture the results can help to reduce the time you spend analyzing the results and can provide a baseline for future testing.

Reading the Output

The IPO report details information in two general sections: whole program analysis and inlining. By default, the report generates a medium level of detail. You can specify an output file to capture the report results. Running maximum IPO report results can be very extensive and technical; specifying a file to capture the results can help to reduce analysis time. The following sample report illustrates the general layout.

Sample IPO Report

IP OPTIMIZATION REPORT:

...

WHOLE PROGRAM (SAFE) [EITHER METHOD]: TRUE

WHOLE PROGRAM (SEEN) [TABLE METHOD]: TRUE

WHOLE PROGRAM (READ) [OBJECT READER METHOD]: TRUE

INLINING OPTION VALUES:

-inline-factor: 100

-inline-min-size: 7

-inline-max-size: 230

-inline-max-total-size: 2000

-inline-max-per-routine: disabled

-inline-max-per-compile: disabled

INLINING REPORT: (main) [1/5=20.0%]

-> INLINE: _Z3bari(6) (isz = 12) (sz = 17 (5+12))

-> _ZNSolsEPFRSoS_E(EXTERN)

...

The following table summarizes the common report elements and provides a general description to help interpret the results.

Report Element

Description
WHOLE PROGRAM (SAFE) [EITHER METHOD]:

TRUE or FALSE.

  • TRUE: The compiler determined, using one or both of the whole program analysis models, that the whole program was present during compilation.

  • FALSE: The compiler determined the whole program was not present during compilation. The compiler could not apply whole program IPO.

See Inteprocedural Optimizations (IPO) Overview for more information on the whole program analysis models.
WHOLE PROGRAM (SEEN) [TABLE METHOD]:

TRUE or FALSE.

  • TRUE: The compiler resolved all references, either within the application code or in the standard table for the functions within the compiler.

  • FALSE: The compiler could not resolve all references. One or more functions references could not be found either in the user code or standard functions table.
WHOLE PROGRAM (READ) [OBJECT READER METHOD]:

TRUE or FALSE.

  • TRUE: The compiler determined that all conditions were met for linking at a level equivalent to the -O0 (Linux and Mac OS X) or /Od (Windows) option.

  • FALSE: The compiler could not resolve one or more references. The linking step failed.
INLINING OPTION VALUES:

Displays the compilation values used for the following developer-directed inline expansion options:

  • inline-factor

  • inline-min-size

  • inline-max-size

  • inline-max-total-size

  • inline-max-per-routine

  • inline-max-per-compile

If you specify the one or more of the appropriate options, the report lists the values you specified; if you do not specify an option and value the compiler uses the defaults values for the listed options, and the compiler will list the default values.

The values indicate the same intermediate language units listed in Compiler Options for each of these options. See Developer Directed Expansion of User Functions for more information about using these options.
INLINING REPORT:

Includes a string in the format of the following

(<name>) [<current number>/<total number>=<percent complete>]

where

  • <name>: the name of the function being reported on.

  • <current number> is the number of the function being reported on. Not every function can be inlined; gaps in the current number are common.

  • <total number> is the total number of functions being evaluated.

  • <percent complete> is a simple percentage of the functions being inlined.
INLINE:

If a function is inlined, the function line has the prefix "-> INLINE: _".

The option reports displays the mangled names of the functions.

The report uses the following general syntax format:

-> INLINE: _<name>(#) (isz) (sz)

where

  • <name> : Indicates the mangled name of the function for C++; for C functions the names are not mangled. Static functions display the mangled function name with numbered suffix.

  • #: Indicates the unique integer specifying the function number.

  • sz: Indicates the function size before optimization. This is a rough estimate loosely representative of the number of original instructions before optimization.

  • isz: Indicates the function size after optimization. This value (isz) will always be less than or equal to the unoptimized size (sz).

  • exec_cnt: Indicates that Profile-guided Optimization was specified during compilation. Indicates the number of times the function was called from this site.

Note iconNote

You can make the mangled names readable by entering the following:

Linux: echo <mangled_name> | c++filt

Windows: undname <mangled_name>

Function calls that could not be inlined lack the INLINE prefix. Additionally, the compiler marks non-inlined functions using the following conventions:

  • EXTERN indicates the function contained an external function call for which the compiler was not supplied the code.

  • ARGS_IN_REGS indicates inlining did not occur.

    For IA-32 and Intel® 64 architectures, an alternative for functions that were not inlined is to allow the compiler to pass the function arguments in registers rather than using standard calling conventions; however, for IA-64 architecture this is the default behavior.
DEAD STATIC FUNCTION ELIMINATION:

Indicates the reported function is a dead static. Code does not need to be created for these functions. This behavior allows the compiler to reduce the overall code size.