Category
Optimization and tuning
Pragma equivalent
#pragma options (optimize) (C only), #pragma options (nooptimize) (C only)
Purpose
Specifies whether to optimize code during compilation and, if so, at which level.
Syntax
.-NOOPT------------. >>-+-OPT--+---------+-+---------------------------------------->< '-(level)-'
Defaults
NOOPTIMIZE
When compiling with HOT, IPA, or SMP, the default is OPTIMIZE(2).
Parameters
- level
- level can have the following values:
- 0
- Indicates that no optimization is to be done; this is equivalent to NOOPTIMIZE. You should use this option in the early stages of your application development since the compilation is efficient but the execution is not. This option also allows you to take full advantage of the debugger.
- 1
- OPTIMIZE(1) is an obsolete artifact of the OS/390® Version 2 Release 4 compiler. We suggest that you use OPTIMIZE(2), which may help avoid compatibility issues.
- 2
- Indicates that global optimizations are to be performed. You should be aware that the size of your functions, the complexity of your code, the coding style, and support of the ISO standard may affect the global optimization of your program. You may need significant additional memory to compile at this optimization level.
- 3
- Performs additional optimizations to those performed with OPTIMIZE(2).
OPTIMIZE(3) is recommended when the need for runtime improvement outweighs
the concern for minimizing compilation resources. Increasing the level
of optimization may or may not result in additional performance improvements,
depending on whether additional analysis detects further opportunities
for optimization. Compilation may require more time and machine resources.
Use the STRICT option with OPTIMIZE(3) to turn off the aggressive optimizations that might change the semantics of a program. STRICT combined with OPTIMIZE(3) invokes all the optimizations performed at OPTIMIZE(2) as well as further loop optimizations. The STRICT compiler option must appear after the OPTIMIZE(3) option, otherwise it is ignored.
The aggressive optimizations performed when you specify OPTIMIZE(3) are:- Aggressive code motion, and scheduling on computations that have the potential to raise an exception, are allowed.
- Conformance to IEEE rules are relaxed. With OPTIMIZE(2), certain optimizations are not performed because they may produce an incorrect sign in cases with a zero result, and because they remove an arithmetic operation that may cause some type of floating-point exception. For example, X + 0.0 is not folded to X because, under IEEE rules, -0.0 + 0.0 = 0.0, which is -X. In some other cases, some optimizations may perform optimizations that yield a zero result with the wrong sign. For example, X - Y * Z may result in a -0.0 where the original computation would produce 0.0. In most cases, the difference in the results is not important to an application and OPTIMIZE(3) allows these optimizations.
- Floating-point expressions may be rewritten. Computations such as a*b*c may be rewritten as a*c*b if, for example, an opportunity exits to get a common subexpression by such rearrangement. Replacing a divide with a multiply by the reciprocal is another example of reassociating floating-point computations.
- no level
- OPTIMIZE specified with no level defaults, depending on the compilation environment and IPA mode.
Usage
When the OPTIMIZE compiler option is in effect, the compiler is instructed to optimize the generated machine instructions to produce a faster running object module. This type of optimization can also reduce the amount of main storage that is required for the generated object module.
Using OPTIMIZE will increase compile time over NOOPTIMIZE and may have greater storage requirements. During optimization, the compiler may move code to increase runtime efficiency; as a result, statement numbers in the program listing may not correspond to the statement numbers used in runtime messages.
The OPTIMIZE option will control the overall optimization value. Any subprogram-specific optimization levels specified at compile time by #pragma option_override(subprogram_name, "OPT(LEVEL,n)") directives will be retained. Subprograms with an OPT(LEVEL,0) value will receive minimal code generation optimization. Subprograms may not be inlined or inline other subprograms. Generate and check the inline report to determine the final status of inlining.
Inlining of functions in conjunction with other optimizations provides optimal runtime performance. The option INLINE is automatically turned on when you specify OPTIMIZE, unless you have explicitly specified the NOINLINE option. See INLINE | NOINLINE for more information about the INLINE option and the optimization information.
If you specify OPTIMIZE with TEST, you can only set breakpoints at function call, function entry, function exit, and function return points. See DEBUG | NODEBUG for more information about the DEBUG option with optimization.
In the z/OS UNIX System Services environment, -g implies NOOPTIMIZE.
A comment that notes the level of optimization will be generated in your object module to aid you in diagnosing your program.
IPA effects
During a compilation with IPA Compile-time optimizations active, any subprogram-specific optimization levels specified by #pragma option_override(subprogram_name, "OPT(LEVEL,n)") directives will be retained. Subprograms with an OPT(LEVEL,0) value will receive minimal IPA and code generation optimization. Subprograms may not be inlined or inline other subprograms. Generate and check the inline report to determine the final status of inlining.
On the IPA compile step, all values (except for (0)) of the OPTIMIZE compiler option and the OPT suboption of the IPA option have an equivalent effect.
OPTIMIZE(2) is the default for the IPA link step, but you can specify any level of optimization. The IPA link step Prolog listing section will display the value of this option.
This optimization level will control the overall optimization value. Any subprogram-specific optimization levels specified at IPA Compile time by #pragma option_override(subprogram_name, "OPT(LEVEL,n)") directives will be retained. Subprograms with an OPT(LEVEL,0)) value will receive minimal IPA and code generation optimization, and will not participate in IPA Inlining.
The IPA link step merges and optimizes your application code, and then divides it into sections for code generation. Each of these sections is a partition. The IPA link step uses information from the IPA compile step to determine if a subprogram can be placed in a particular partition. Only compatible subprograms are included in a given partition. Compatible subprograms have the same OPTIMIZE setting.
The OPTIMIZE setting for a partition is set to that of the first subprogram that is placed in the partition. Subprograms that follow are placed in partitions that have the same OPTIMIZE setting. An OPTIMIZE(0) mode is placed in an OPTIMIZE(0) partition, and an OPTIMIZE(2) is placed in an OPTIMIZE(2) partition.
The option value that you specified for each IPA object file on the IPA compile step appears in the IPA link step Compiler Options Map listing section.
The Partition Map sections of the IPA link step listing and the object module END information section display the value of the OPTIMIZE option. The Partition Map also displays any subprogram-specific OPTIMIZE values.
If you specify OPTIMIZE(2) for the IPA link step, but only OPTIMIZE(0) for the IPA compile step, your program may be slower or larger than if you specified OPTIMIZE(2) for the IPA compile step. This situation occurs because the IPA compile step does not perform as many optimizations if you specify OPTIMIZE(0).
Refer to the descriptions for the OPTIMIZE and LEVEL suboptions of the IPA option in IPA | NOIPA for information about using the OPTIMIZE option under IPA.
Predefined macros
__OPTIMIZE__ is defined to the value specified by the OPTIMIZE compiler option; it is undefined if NOOPTIMIZE is used.