Skip to main content

IAR Embedded Workbench for Arm 10.10.x

Optimization levels

In this section:

The compiler supports different levels of optimizations. This table lists which optimizations that are typically performed by default on each level. Note that optimizations that are performed at more than one level, are usually allowed to be more aggressive at higher optimization levels.

Optimization

None (best debug support)

Low

Medium

High (balanced)

To override

Dead code elimination

Redundant label elimination

Redundant branch elimination

Variables only live for as long as they are needed

Code hoisting

Common sub-expression elimination

‑‑no_cse

Live-dead analysis and optimization

Redundant computation elimination

Static clustering

‑‑no_clustering

Value-based optimizations

Value propagation and simplification

Code motion

‑‑no_code_motion

Peephole optimization

Cross jumping

‑‑no_cross_jump

Function inlining

‑‑no_inline

Instruction scheduling

‑‑no_scheduling

Loop unrolling

‑‑no_unroll

Type-based alias analysis

‑‑no_tbaa

Note

Some of the default optimizations at a specific level can be individually disabled, as seen in the To override column. See also Fine-tuning enabled transformations.

A high level of optimization might result in increased compile time, and will also most likely make debugging more difficult, because it is less clear how the generated code relates to the source code. For example, at the low, medium, and high optimization levels, variables do not live through their entire scope, which means processor registers used for storing variables can be reused immediately after they were last used. Due to this, the C-SPY Watch window might not be able to display the value of the variable throughout its scope, or even occasionally display an incorrect value. At any time, if you experience difficulties when debugging your code, try lowering the optimization level.