Reading What the Compiler Produced

Almost every question an engineer has about compiler behaviour is one of four, and each has a direct answer that takes less than a minute. Learning these four is worth more than any amount of reasoning about what the compiler "probably" did.

"What did it generate?" — clang -O2 -S -o - file.c or gcc -O2 -S -o - file.c prints assembly to stdout. Add -fverbose-asm on GCC for comments naming the variables behind the registers, and -masm=intel (GCC) or -masm=intel/--x86-asm-syntax=intel (Clang/LLVM tools) if you prefer Intel syntax. For an already-built artifact, objdump -d --demangle or llvm-objdump -d --demangle, and objdump -dS to interleave the source.

"What did the middle-end see?" — clang -O2 -S -emit-llvm -o - file.c prints LLVM IR. The single most informative thing in this whole lesson is to run it twice, once at -O0 and once at -O2, and diff: the difference is the entire middle-end, made concrete.

"Did optimization X happen, and if not, why not?" — optimization remarks, covered in the next section. This is the flag most engineers do not know exists and the one that most often ends an investigation immediately.

"What is in this binary?" — nm -C --defined-only for symbols, readelf -sW for the full symbol table with sizes, readelf -SW for sections, size -A for section sizes, readelf -d for dynamic dependencies, strings for embedded text. On macOS nm, otool -tv, otool -L; on Windows dumpbin /disasm, /symbols, /dependents.

This is the part most engineers have never used and the part that most often ends an investigation in one command. Both GCC and Clang can report, per transformation, whether it fired — and when it did not, what specifically prevented it.

GCC uses -fopt-info, with a group and a filter: -fopt-info-vec-optimized for vectorized loops, -fopt-info-vec-missed for the ones that were not and why, -fopt-info-inline-optimized, -fopt-info-loop-all, and -fopt-info-all=report.txt to write everything to a file. -fopt-info-vec-missed is the one to memorise: it prints lines such as "not vectorized: complicated access pattern" or "not vectorized: unsupported data-type" against the source line, which is a direct answer to the question everyone asks about a hot loop.

Clang uses -Rpass=, -Rpass-missed= and -Rpass-analysis=, each taking a regular expression matching pass names. -Rpass=loop-vectorize reports successes; -Rpass-missed=loop-vectorize reports failures; -Rpass-analysis=loop-vectorize reports the analysis that led to the failure, which is the one with the actual reason in it. -Rpass=inline and -Rpass-missed=inline do the same for inlining, and the missed remarks name the cost-model decision.

For anything more than a quick look, -fsave-optimization-record writes a YAML file per translation unit, and LLVM ships opt-viewer.py to render it as source annotated with every remark. That is the right tool when you are working through a whole file rather than one loop.

The reason this matters more than reading assembly: assembly tells you *what*, and a remark tells you *why*. "It did not vectorize" is where most investigations stop; "not vectorized: possible dependence between loads and stores" tells you to add restrict or restructure the access, and that is an actionable answer you did not have to infer.

Assembly output contains a great deal that is not instructions, and knowing what to ignore is most of the skill. .cfi_startproc, .cfi_def_cfa_offset and their relatives are unwind directives — [[stack-unwinding]] metadata, not code. .loc directives are line-table entries. .p2align is padding. .section, .globl, .type and .size are bookkeeping for the assembler and linker. On a first read, skip all of them and look only at the mnemonics.

Then apply a few habits that turn an unreadable dump into an answer.

Compile the smallest possible function. A twenty-line function produces readable output; a real translation unit does not. Extract the loop into its own file with the same flags.

Give the function external linkage and no callers, so it is not inlined away and does actually get emitted. A static function with no uses will simply not appear.

Find the loop first. Look for a backward branch to a label above the current position. Everything between the label and that branch is the loop body, and counting its instructions is the single most useful measurement you can take.

Name the target. Register names, instruction availability and the calling convention all depend on the triple. Any conclusion drawn without knowing whether you compiled for x86-64 or AArch64 is not transferable, which is why every listing in this domain carries a target label.

Diff, do not read. The highest-value use of Compiler Explorer is two panes with different flags or different compiler versions side by side. The absolute output is hard to judge; the difference between two outputs is usually obvious.

The browser tool at godbolt.org compiles a snippet with dozens of compilers and versions and shows the assembly next to the source, with colour-coded correspondence between them. It is the fastest way to answer a question about compiler behaviour and it is worth being precise about which questions it is good for.

It is excellent for: comparing two flag sets on the same code; comparing GCC against Clang against MSVC on the same code; comparing two versions of the same compiler to see when behaviour changed; checking whether an idiom compiles to what you assumed; and settling an argument in a code review with a link. The colour mapping between source lines and instruction groups makes the correspondence legible without reading a line table.

It is not good for: anything depending on your real build flags, your headers, your inlining context, or link-time optimization. A snippet compiled in isolation is not the code in your project, and a function that looks tight standalone can be inlined into a caller and optimized completely differently. It is a hypothesis generator, and the hypothesis should then be checked against your actual build.

The final and most important point, which applies to every tool in this lesson: reading the output tells you what the compiler did; it does not tell you what is fast. Instruction count is not time. A shorter sequence with a dependency chain can lose to a longer one with independent work; a vectorized loop can be slower if it is memory-bound; the out-of-order machine underneath reorders again, which is Computer Architecture’s subject and not visible at this level. The compiler output answers "did the transformation happen". Whether it helped is a measurement, and it belongs to a profiler.