Functions to be inlined must pass all the criteria (inline,
inline_depth, inline_looplevel ) to be inlined. The following
directives are exceptions to this rule.
The #pragma _KAP [no]inline and
#pragma _KAP [no]ipa directives, when enabled,
override the /inline and /ipa command
qualifiers, respectively.
A #pragma _KAP inline global directive
without a function name list tells KAP to inline every
function possible, regardless of the inline ,
inline_depth , and inline_looplevel
settings. A #pragma _KAP noinline global
directive tells KAP not to inline anything, regardless of the
inline , inline_depth , and inline_
looplevel settings.
When a library is specified with /inline_from_libraries
, functions may be taken from that library for inlining into the
source code. No attempt is made to inline functions from the source
file into functions from the library. For example, if the main
program calls function bb , which is in the library,
and bb calls function dd , which is in
the source file, then bb can be inlined into the main
program, but KAP will not attempt to inline dd into the
text from library function bb .
A library created with /inline_create will work for
inlining or IPA because it is just partially reduced source code.
However, a library created with /ipa_create may not
appear in an /inline_from_libraries= list; it is
flagged with a Warning message.
Inlining and IPA are slow, memory-intensive activities. Specifying
/inline_depth=10 /inline_looplevel=<big> , that
is, inline all available functions everywhere they are used,
for a large set of inlinable functions for a large source file
can absorb significant system resources. For most programs,
specifying small values for /inline_depth and
/inline_looplevel and/or a small number of functions
with /inline= can provide most of the benefits of
inlining. The same applies for the corresponding /ipa
command qualifiers.