Optimizing Itanium-Based Applications (May 2011)

18
+inline_level n
Fine tunes the aggressiveness of the inliner. The value of <n> can be in the range 0.0-9.0 with 0.1
increments. The following values/ranges have special meaning:
 0.0: No inlining is done (same as +d).
 1.0: Only functions marked with the inline keyword or implied by the language to be inline are
considered for inlining.
 1.0 < num < 2.0 : increasingly make inliner more aggressive below the default level.
 2.0: Default level of inlining for +O2,+O3,+O4.
 2.0 < num < 9.0 : increasingly aggressive inlining.
 9.0: Most aggressive inlining.
+O[no]procelim (default +Oprocelim)
Enables or disables elimination of procedures that are never called. Those marked with hidden export
class are deleted, in addition to unreferenced non-hidden non-static symbols. This option reduces
executable size, which can improve TLB and instruction cache behavior.
+Otype_safety=[off|limited|ansi|strong]
(default +Otype_safety=off, can become limited)
These options are only supported for C applications. These options are used to indicate what type of
aliasing guarantees the compiler can assume when optimizing code. Applications might not execute
correctly if the specified option guarantees a degree of type-safety that is not actually followed in the
code. +Otype_safety=off is the most conservative, and says that objects of all types can alias each
other. Using +Otype_safety=limited specifies that the code follows ANSI aliasing rules, and
that unnamed objects should be treated as if they had unknown type. In other words, objects of type
float and of type int can be assumed to touch different memory locations, and accesses to these
differently-typed objects can be freely scheduled across one another. It does not disambiguate accesses
of different types when both accesses can touch unnamed memory. In addition, as ANSI rules specify,
character objects can touch objects of other types, and must be optimized conservatively with respect to
other objects. Using +Otype_safety=ansi specifies that the code follows ANSI aliasing rules, and
that unnamed objects should be treated the same as named objects. The most aggressive disambiguation
is allowed with +Otype_safety=strong, which says that code follows ANSI aliasing rules, except
that accesses through lvalues of character type are not permitted to touch objects of other types, and it is
assumed that structure and union field addresses are not taken.
+O[no]ptrs_to_globals (default +Optrs_to_globals)
With +Optrs_to_globals, it is assumed that statically-allocated data (including file-scoped
globals, file-scoped statics, and function-scoped statics) is not read or written through pointers. This
allows more aggressive optimization and scheduling of pointer-intensive code.
This option is unnecessary when compiling with –ipo or +O4, as interprocedural analysis will apply it
automatically where legal.
+O[no]cross_region_addressing (default +Onocross_region_addressing)
Enables/disables use of cross-region addressing. Enabling this option results in more conservative
address computation, and a loss in performance. It is required if pointers (including array base pointers)
might point to a different region than data being accessed as an offset off of that pointer. This does not
occur in standard-conforming applications. If it does occur, and the option is enabled, the compiler is
not able to take advantage of post-incrementing load and store instructions, because it does not know
when the address might cross into another region. This option has no effect under +DD64.
+[no]parmsoverlap (default +Oparmsoverlap)
Not applicable to Fortran