|
VMS Help CXX, Qualifiers, /OPTIMIZE *Conan The Librarian |
/OPTIMIZE
/OPTIMIZE[=option]
/OPTIMIZE=(LEVEL=4,INLINE=AUTOMATIC,INTRINSICS,UNROLL=0,
NOOVERRIDE_LIMITS,TUNE=GENERIC) (D)
/NOOPTIMIZE
Controls the level of code optimization that the compiler
performs. The options are as follows:
Option Usage
LEVEL=n Selects the level of code optimization. Specify
an integer from 0 (no optimization) to 5 (full
optimization).
[NO]INLINE Provides inline expansion of functions that yield
optimized code when they are expanded. You can
specify one of the following keywords to control
inlining:
NONE No inlining is done, even if requested by
the language syntax.
MANUAL Inlines only those function calls for
which the program explicitly requests
inlining.
AUTOMATIC Inlines all of the function calls in
the MANUAL category, plus additional
calls that the compiler determines are
appropriate on this platform. On Alpha
systems, the heuristics for AUTOMATIC
are similar to those for SIZE; on I64
systems, they are more like those for
SPEED. AUTOMATIC is the default.
SIZE Inlines all of the function calls in
the MANUAL category plus any additional
calls that the compiler determines would
improve run-time performance without
significantly increasing the size of the
program.
SPEED Performs more aggressive inlining for
run-time performance, even when it might
significantly increase the size of the
program.
ALL Inlines every call that can be inlined
while still generating correct code.
Recursive routines, however, will not
cause an infinite loop at compile time.
On I64 systems, ALL is treated as if SIZE
had been specified.
Note that /OPT=INLINE=ALL is not
recommended for general use, because
it performs very aggressive inlining and
can cause the compiler to exhaust virtual
memory or take an unacceptably long time
to compile.
[NO]OVERRIDE_ Controls whether or not the compiler uses certain
LIMITS (I64 built-in limits on the size and complexity of
only) a function to "throttle back" the amount of
optimization performed in order to reduce the
likelihood that the compiler will use excessive
memory resources or CPU time attempting to optimize
the code.
The default is NOOVERRIDE_LIMITS, which means that
when compiling a function that has an unusually
large number of basic blocks, live variables, or
other properties that tend to cause the optimizer
to use extra resources, the informational message
OPTLIMEXC might be issued to notify you that
optimization has been reduced to avoid excessive
resource use.
You can choose to ignore this message or disable
it (the message is not issued on compilations with
optimization disabled).
Or you can specify /OPTIMIZE=OVERRIDE_LIMITS, which
instructs the compiler to not check the limits and
to attempt full optimization no matter how large or
complex the function, knowing that the compilation
might exhaust memory or seem to be in a loop.
If using /OPTIMIZE=OVERRIDE_LIMITS does result
in excessive resource use, you are sure that
the compiler process has plenty of memory quota
available, you are convinced that the compilation
does not contain any unusually large or complex
functions, and you can provide complete source
code, then you might want to contact your support
channel to see if there is a problem in the
compiler causing it to use more resources than
it should for the particular compilation at hand.
TUNE Specifies the preferred processor for execution.
This option makes some decisions preferentially
for the specified processor (for example, for code
scheduling). Note that code valid only for the
specified processor can be generated. However,
parallel code can be generated for processors down
to the specified architecture level if necessary;
that is, tuning specifies the preferred target,
while architecture level specifies a lower boundary
on available processor features.
For example, /ARCHITECTURE=EV56/OPTIMIZE=TUNE=EV6
specifies that the code does not need to run on
a processor older than an EV56, and that the code
will probably run on an EV6. The generated code
will run on all EV56 and later systems without any
emulation. The code might have run-time selected
conditional regions specifically for EV6. Also,
note that because emulation is provided, the code
should run, but potentially at very significantly
reduced speed, on pre-EV56 processors.
The options for TUNE are the same as the options
for /ARCH. You can specify one of the following
keywords:
GENERIC Selects instruction tuning
that is appropriate for all
implementations of the operating
system architecture. This option is
the default.
HOST Selects instruction tuning that is
appropriate for the machine on which
the code is being compiled.
ITANIUM2 Selects instruction tuning for the
(I64 only) Intel Itanium 2 processor.
EV4 (Alpha Selects instruction tuning for the
only) 21064, 21064A, 21066, and 21068
implementations of the operating
system architecture.
EV5 (Alpha Selects instruction tuning for
only) the 21164 implementation of the
operating system architecture.
EV56 (Alpha Selects instruction tuning for
only) 21164 chip implementations that
use the byte- and word-manipulation
instruction extensions of the Alpha
architecture.
Running programs compiled with the
EV56 keyword might incur emulation
overhead on EV4 and EV5 processors,
but will still run correctly on
OpenVMS Version 7.1 (or later)
systems.
PCA56 (Alpha Selects instruction tuning for the
only) 21164PC chip implementation that
uses the byte- and word-manipulation
instruction extensions and
multimedia instruction extensions
of the Alpha architecture.
Programs compiled with the PCA56
keyword might incur emulation
overhead on EV4, EV5, and EV56
processors, but will still run
correctly on OpenVMS Version 7.1
(or later) systems.
EV6 (Alpha Selects instruction tuning for
only) the first-generation 21264
implementation of the Alpha
architecture.
EV67 (Alpha Selects instruction tuning for
only) the second-generation 21264
implementation of the Alpha
architecture.
[NO]INTRINSICSControls whether certain functions are handled as
intrinsic functions without explicitly enabling
each of them as an intrinsic through the #pragma
intrinsic preprocessor directive.
Functions that can be handled as intrinsics are:
Main Group - ANSI:
abs atanl atan2l ceill cosl floorf memcpy sinf
atan atan ceil cos fabs floorl memmove sinl sin
atanf atan2f ceilf cosf floor labs memset strcpy strlen
Main Group - Non-ANSI:
alloca atand2 bzero sind
atand bcopy cosd
Printf functions:
fprintf printf sprintf
Printf non-ANSI:
snprintf
ANSI math functions that set errno, thereby
requiring /ASSUME=NOMATH_ERRNO:
acos asinf coshl log log10f powl sqrt tanf
acosf asinl exp logf log10l sinh sqrtf tanl
acosl cosh expf logl pow sinhf sqrtl tanh tanhl
asin coshf expl log10 powf sinhl tan tanhf
Non-ANSI math functions that set errno, thereby
requiring /ASSUME=NOMATH_ERRNO:
log2 tand
The /OPTIMZE=INTRINSICS qualifier works with
/OPTIMIZE=LEVEL =n and some other qualifiers to
determine how intrinsics are handled:
o If the optimization level specified is less than
4, the intrinsic-function prototypes and call
formats are checked, but normal run-time calls
are still made.
o If the optimization level is 4 or higher,
intrinsic code is generated.
o Intrinsic code is not generated for math
functions that set the errno variable unless
/ASSUME=NOMATH_ERRNO is specified. Such math
functions, however, do have their prototypes and
call formats checked.
The default is /OPTIMIZE=INTRINSICS, which turns
on this handling.
To turn it off, use /NOOPTIMIZE or
/OPTIMIZE=NOINTRINSICS.
UNROLL=n Controls loop unrolling done by the optimizer.
Specify a positive integer to indicate the number
of times to unroll loop bodies. If you specify 0
or do not supply a value, the optimizer determines
its own unroll amount. The default is UNROLL=0.
Specifying UNROLL=1 effectively disables loop
unrolling.
On I64 systems, you do not have the ability to
control the number of times a loop is unrolled. You
can either disable loop unrolling with UNROLL=1,
or accept the UNROLL=0 default, which lets the
optimizer determine the unroll amount.
The default is /OPTIMIZE, which is equivalent to
/OPTIMIZE=LEVEL=4.
|
|