C++ Compiler Optimization

Why Compiler Optimization Matters

The difference between -O0 and -O2 is typically 5-10x in execution speed. Between -O0 and -O3 with auto-vectorization, it can be 20-40x for numerical code. The important skill is not memorizing flags. It is learning to ask: what rewrite did the compiler prove safe, what tradeoff did it make, and how do I verify the result?

Think of optimization as a lab workflow:

• choose a starting level such as -O2
• inspect the generated assembly or compiler remarks
• fix source-level blockers like aliasing or dependencies
• add LTO or PGO only when measurement justifies it
• treat unsafe flags as explicit correctness decisions

Optimization levels

Each -O level enables progressively more aggressive optimizations. The difference isn’t just “faster” — the compiler generates fundamentally different assembly at each level:

int sum_array(int* arr, int n) {
    int sum = 0;
    for (int i = 0; i < n; i++)
        sum += arr[i];
    return sum;
}

_Z9sum_arrayPii:
	endbr64
	test	esi, esi
	jle	.L4
	lea	eax, -1[rsi]
	lea	rdx, 4[rdi+rax*4]
	xor	eax, eax
.L3:
	add	eax, DWORD PTR [rdi]
	add	rdi, 4
	cmp	rdi, rdx
	jne	.L3
	ret
.L4:
	xor	eax, eax
	ret

Transformation passes

Tail-call elimination is another control-flow transformation: when a caller has no work left after a call, the compiler may transfer directly to the callee. The linked concept shows stack behavior and CPython 3.14’s use of tail calls between opcode handlers.

Compiler passes are the individual rewrites behind the optimization level. One pass folds constants, another removes dead code, another hoists loop-invariant work, and another rewrites expensive indexing into cheaper increments.

Use this lab to connect the human-readable source change to the mechanical compiler transformation:

int calculate() {
    int a = 2 * 3;
    int b = 10 / 2;
    int c = a + b;
    return c * 4;
}

int calculate() {
    return 44;
    // 2*3=6, 10/2=5
    // 6+5=11, 11*4=44
}

Vectorization

Auto-vectorization is where source shape matters most. At -O3 or with explicit vectorization flags, the compiler tries to convert scalar loops into SIMD instructions. It succeeds only when it can prove that iterations are independent and memory accesses are safe.

void add_arrays(float* a, float* b,
               float* c, int n) {
    for (int i = 0; i < n; i++)
        c[i] = a[i] + b[i];
}

g++ -O2 -march=native -ftree-vectorize -fopt-info-vec-optimized source.cpp
clang++ -O2 -march=native -Rpass=loop-vectorize -Rpass-missed=loop-vectorize source.cpp

When vectorization fails, the fix is usually structural: remove loop-carried dependencies, make memory access contiguous, or give the compiler a legal no-alias promise such as __restrict__.

Compiler flags and verification

Once local transformations look good, production builds usually add two more layers:

• LTO: lets the optimizer see across .cpp file boundaries during linking. This enables cross-file inlining and whole-program dead function elimination.
• PGO: uses representative runtime profiles to make better branch layout, inlining, and hot/cold code placement decisions.
• Reports: make the compiler tell you what it optimized, missed, or spent time on.

Use the flag builder as the final lab step. Start with -O2, add one idea at a time, then verify with compiler reports and benchmarks instead of assuming the flag helped.

g++ -O2 -march=native -Wall -Wextra source.cpp -o binary

godbolt.org is still the fastest manual check: paste one function, compare -O2 and -O3, inspect whether the branch disappeared or the loop vectorized, then decide whether the real code deserves a build-system change.

Further Reading

• Godbolt Compiler Explorer - Instant assembly output for any C++ code, any compiler
• GCC Optimization Options - Complete reference for GCC optimization flags
• Clang/LLVM Optimization Remarks - How to read Clang’s optimization diagnostics
• What Every Programmer Should Know About Compiler Optimizations - Microsoft’s overview of key compiler optimizations

Related concepts