CodeGenOptLevel

Disable as many optimizations as possible. This doesn’t completely disable the optimizer in all cases, for example always_inline functions can be required to be inlined for correctness.

Optimize quickly without destroying debuggability.

This level is tuned to produce a result from the optimizer as quickly as possible and to avoid destroying debuggability. This tends to result in a very good development mode where the compiled code will be immediately executed as part of testing. As a consequence, where possible, we would like to produce efficient-to-execute code, but not if it significantly slows down compilation or would prevent even basic debugging of the resulting binary.

As an example, complex loop transformations such as versioning, vectorization, or fusion might not make sense here due to the degree to which the executed code would differ from the source code, and the potential compile time cost.

Optimize for fast execution as much as possible without triggering significant incremental compile time or code size growth.

The key idea is that optimizations at this level should “pay for themselves”. So if an optimization increases compile time by 5% or increases code size by 5% for a particular benchmark, that benchmark should also be one which sees a 5% runtime improvement. If the compile time or code size penalties happen on average across a diverse range of LLVM users’ benchmarks, then the improvements should as well.

And no matter what, the compile time needs to not grow superlinearly with the size of input to LLVM so that users can control the runtime of the optimizer in this mode.

This is expected to be a good default optimization level for the vast majority of users.

Optimize for fast execution as much as possible.

This mode is significantly more aggressive in trading off compile time and code size to get execution time improvements. The core idea is that this mode should include any optimization that helps execution time on balance across a diverse collection of benchmarks, even if it increases code size or compile time for some benchmarks without corresponding improvements to execution time.

Despite being willing to trade more compile time off to get improved execution time, this mode still tries to avoid superlinear growth in order to make even significantly slower compile times at least scale reasonably. This does not preclude very substantial constant factor costs though.

Returns the underlying LLVMCodeGenOptLevel associated with this optimization level.