Currently Defined Options

Currently Defined Options

The Licensed Internal Code options that are currently defined are:

[No]AlwaysTryToFoliate : Instructs the optimizing translator, when compiling at optimization level 40, to more aggressively attempt an optimization known as call foliation, which attempts to reduce the number of stack frames maintained on the runtime call stack. The advantage to this is that, in some cases, fewer stack frames may be required, which can improve locality of reference and, in rare circumstances, reduce the possibility of runtime stack overflow. The disadvantage is that, in the event of program failure, there may be fewer clues that are left behind in the call stack when you debug. This option is off by default.

[No]CallTracingAtHighOpt : Use this option to request that call and return traps be inserted into the procedure prologue and epilogue, respectively, of procedures that require a stack, even at optimization level 40. The advantage of inserting call and return traps is the ability to use job trace, while the disadvantage is potentially worse runtime performance. In releases before 6.1, this option is off by default, meaning that no call and return traps are inserted into any procedures at optimization level 40. Beginning in 6.1, this option is ignored and call and return traps are unconditionally inserted in procedures which require a stack, even at optimization level 40.

[No]Compact : Use this option to reduce code size where possible, at the expense of execution speed. This is done by inhibiting optimizations that replicate or expand code inline. This option is off by default.

CodeGenTarget= : The CodeGenTarget option specifies the creation target model for a program or module object. The creation target model indicates the hardware features that the code generated for that object can use. See the following table for the possible values of this LICOPT.

| Value | Meaning |
| --- | --- |
| CodeGenTarget=Current | The optimizing translator can use all features available on the current machine. |
| CodeGenTarget=Common | The optimizing translator can use any feature that is available on every system supported by the target release. |
| CodeGenTarget=Legacy | The optimizing translator cannot use any features that are only available in the POWER6 level of the PowerPC® AS architecture and later. |
| CodeGenTarget=Power6 | The optimizing translator can use all features available in the POWER6 level of the PowerPC AS architecture. |
| CodeGenTarget=Power7 | The optimizing translator can use all features available in the POWER7 level of the PowerPC AS architecture. |
| CodeGenTarget=Power8 | The optimizing translator can use all features available in the POWER8 level of the PowerPC AS architecture. |
| CodeGenTarget=Power9 | The optimizing translator can use all features available in the POWER9 level of the PowerPC AS architecture. |

For more information about this option, refer to [The CodeGenTarget LICOPT](/doc/en/docs/ile-concepts/codegentargetlicopt/#codegentargetlicopt).

[No]CreateSuperblocks : This option controls formation of superblocks, which are large extended basic blocks with no control flow entry except in the superblock header. It also controls certain optimizations performed on superblocks, such as trace unrolling and trace peeling. Superblock formation and optimizations can cause large amount of code duplication; this LICOPT can be used to disable these optimizations. This LICOPT is only effective when profile data is applied. This option is on by default.

[No]DetectConvertTo8BytePointerError : This option is ignored on systems running 6.1 or later. Every conversion from a 16-byte pointer to an 8-byte pointer signals an MCH0609 exception if the 16-byte pointer does not contain a teraspace address and does not contain a null pointer value.

[No]EnableInlining : This option controls procedure inlining by the optimizing translator. Procedure inlining means a call to a procedure is replaced by an inline copy of the procedure code. This option is on by default.

[No]FoldFloat : Specifies that the system may evaluate constant floating-point expressions at compile time. This LICOPT overrides the ‘Fold float constants’ module creation option. When this LICOPT isn’t specified, the module creation option is honored.

LoopUnrolling= : Use the LoopUnrolling option to control the amount of loop unrolling performed by the optimizing translator. Valid values are 0 to disable loop unrolling, 1 to unroll small loops with an emphasis on reducing code duplication, and 2 to aggressively unroll loops. Using option 2 may substantially increase the size of generated code. The default value is 1.

[No]Maf : Permit the generation of floating-point multiply-add instructions. These instructions combine a multiply and an add operation without an intermediate rounding operation. Execution performance is improved, but computational results may be affected. This LICOPT overrides the ‘Use multiply add’ module creation option. When this LICOPT isn’t specified, the module creation option is honored.

[No]MinimizeTeraspaceFalseEAOs : Effective address overflow (EAO) checking is done as part of address arithmetic operations for 16-byte pointers. The same generated code must handle both teraspace and single-level storage (SLS) addresses, so valid teraspace uses can incur false EAOs if the code was generated for a processor before POWER6. See Adaptive Code Generation for more information. These EAO conditions do not indicate a problem, but handling them adds significant processing overhead. The MinimizeTeraspaceFalseEAOs LICOPT causes differences in the hardware instruction sequences generated for the program. Different address arithmetic instruction sequences are generated that are slightly slower in the usual case but eliminate most EAO occurrences. An example of when this LICOPT should be used is when most address arithmetic performed in a module computes teraspace address results to a lower-valued 16 MB area. This option is off by default.

[No]OrderedPtrComp : Use this option to compare pointers as unsigned integer values, and to always produce an ordered result (equal, less than, or greater than). When you use this option, pointers that refer to different spaces will not compare unordered. This option is off by default.

[No]PredictBranchesInAbsenceOfProfiling : When profile data is not provided, use this option to perform static branch prediction to guide code optimizations. If profile data is provided, the profile data will be used to predict branch probabilities instead, regardless of this option. This option is off by default.

[No]PtrDisjoint : This option enables an aggressive typed-based alias refinement that allows the optimizing translator to eliminate a larger set of redundant loads, which may improve runtime performance. An application can safely use this option if the contents of a pointer are not accessed through a non-pointer type. The following expression in C demonstrates an unsafe way to access the value of a pointer:

```
void* spp;
... = ((long long*) &spp) [1]; // Access low order 8 bytes of 16-byte pointer
```

Default:
NoPtrDisjoint

[No]ReassocForIndexedLdSt : This option instructs the optimizing translator to reassociate addressing expressions that feed load or store instructions so that they meet the requirements for conversion into indexed load or store instructions. In most cases, this means searching for load or store instructions with a nonzero displacement that might be transformable into indexed loads or store instructions had the displacement been zero. In this case, reassociation generates an explicit addition of the displacement into the address expression, and the displacement in the load or store instructions is zero.

The default of this
Licensed Internal Code is ReassocForIndexedLdSt.

[No]TailCallOptimizations : This option instructs the optimizing translator, when it compiles at optimization level 40, to perform tail call optimizations that attempt to reduce the number of stack frames that are maintained on the runtime call stack. The advantage to this is that, in some cases, fewer stack frames might be required, which can improve locality of reference and, in rare circumstances, reduce the possibility of runtime stack overflow. The disadvantage is that, if a program fails, fewer clues are left in the call stack that can be used for debugging. It is recommended that this LICOPT remain enabled.

A *tail call* is a call in the procedure that is done immediately before returning.
In these cases, the optimizing translator attempts to perform tail call optimizations that eliminate
the need for the caller to allocate a stack frame and leave the stack unaltered. Normally, a stack
frame is created by the caller to allow the callee to save and restore the return address. With
these optimizations, the tail call is changed to a simple branch operation that does not calculate a
new return address. The original return address is left intact and therefore points back to the
return location of the caller. The optimizations eliminate the intermediate stack frame between the
caller and callee, and the callee returns to the caller's caller.

For example, if Function A calls Function B and Function B does a tail call to Function C, with tail call optimizations enabled, Function B
does not allocate a stack frame and instead branches to Function C. When Function C is
complete, it returns directly back to Function A following the call to Function B. Without tail call
optimizations, Function C returns to Function
B, which immediately returns back to Function A.

For frequently called procedures, tail call optimizations can improve performance by eliminating
the operations needed to create and destroy an unnecessary stack frame. If you specify the LICOPT
value `NoTailCallOptimizations`, these optimizations are not attempted.

The default of this LICOPT is `TailCallOptimizations`.

TargetProcessorModel= : The TargetProcessorModel option instructs the translator to perform optimizations for the specified processor model. Programs created with this option run on all supported hardware models, but generally run faster on the specified processor model. See the following table for the TargetProcessorModel values, associated processor models, and target release-specific defaults for the option.

| Target release of program | `TargetProcessorModel` value | Specified processor model |
| --- | --- | --- |
| IBM i 7.3 and IBM i 7.2 | 6 | POWER8 |
| IBM i 7.1 | 5 | POWER7 |
| IBM i 6.1 | 4 | POWER6 |
| V5R4 and earlier | 3 | POWER5POWER5 |

The `TargetProcessorModel` LICOPT is one of several factors
determining which processor model should be targeted when creating a module, changing a module or
bound module, or re-creating a module or bound module. The following rules apply to both modules and
bound modules.

- When a module is created or changed, and the `TargetProcessorModel` LICOPT is
  specified, the generated code for the module is tuned for best performance on the specified
  processor model, regardless of whether the `CodeGenTarget` LICOPT is also
  specified.
- When a module is created or changed, and the
  `TargetProcessorModel` LICOPT is not specified, but the
  `CodeGenTarget` LICOPT is specified to be POWER6, POWER7, POWER8, or POWER9, the generated code for the module is tuned for best performance on the specified
  processor model.
- When a module is created or changed, and the `TargetProcessorModel` LICOPT is not
  specified, but the `CodeGenTarget` LICOPT is specified to be Current, the generated code for the module is tuned for best
  performance on the processor in use by the partition on which the module resides.
- When a module is created or changed, and the
  `TargetProcessorModel` LICOPT is not specified, but the
  `CodeGenTarget` LICOPT is specified to be Common, then the module is tuned for best
  performance on a default processor model for the release. The default processor model is POWER8 for IBM i 7.3
  and IBM i 7.2, POWER7 for IBM i 7.1, POWER6 for
  IBM i 6.1, and POWER5 for earlier supported releases.
- When a module is created or changed, and the `TargetProcessorModel`  LICOPT is
  not specified, but the `CodeGenTarget` LICOPT is specified to be Legacy, then the
  module is tuned for best performance on the POWER5 processor model.
- When a module is re-created, the module is tuned for best performance on the processor in use by
  the partition on which the module resides, regardless of the values of any
  `TargetProcessorModel` and `CodeGenTarget` LICOPTs specified when the
  module was created or last changed.

Note that for most of these options there is a positive and a negative variation, the negative beginning with the prefix ‘no’. The negative variant means that the option is not to be applied. There will always be two variants like this for Boolean options, in order to allow a user to explicitly turn off an option as well as turn it on. The capability to do so is necessary to turn off an option for which the default option is on. The default for any option may change from release to release.