CodeGenOptLevel

public enum CodeGenOptLevel

LLVM-provided high-level optimization levels.

Each level has a specific goal and rationale.

  • 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.

    Declaration

    Swift

    case none
  • 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.

    Declaration

    Swift

    case less
  • 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.

    Declaration

    Swift

    case `default`
  • 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.

    Declaration

    Swift

    case aggressive
  • Returns the underlying LLVMCodeGenOptLevel associated with this optimization level.

    Declaration

    Swift

    public func asLLVM() -> LLVMCodeGenOptLevel