Study LLVM IR: Compile C Code and Read the .ll Output

Topic Overview

LLVM IR in Production

LLVM IR is the interchange format behind Clang, Rust, Swift, Julia, and many GPU compilers. It is typed, SSA-based, and infinite-register. Reading .ll output at -O0 vs -O2 is how engineers diagnose missed optimizations and undefined-behavior surprises.

Module Structure

A module contains functions. Each function has basic blocks of instructions. Types are explicit: i32, float, pointers. The phi instruction merges SSA values. alloca, load, and store model stack memory.

llvmCopy
Loading…

• clang -S -emit-llvm foo.c produces .ll text
• SSA names use % prefix; globals use @
• Optimizations run as pass pipelines on IR
• IR is both human-readable text and bitcode binary

Connecting to real compilers

Production compilers embed this step inside a longer pipeline. GCC flows through cpp, cc1, assembly, and ld; Clang uses the driver, Sema, LLVM IR passes, and a target backend. LLVM bitcode, JVM bytecode, and WASM are other familiar IRs at the same layer. The exercise isolates one pass so you can test it alone before chaining it to the next stage.

Why for this exercise

You will study LLVM IR by compiling C code with Clang and reading the .ll output. This exercise asks you to trace how C constructs map to LLVM instructions and compare unoptimized vs optimized IR for the same source.

Your Task

Clang can't run in this sandbox, so this task gives you its output: an LLVM IR function, as clang -S -emit-llvm would print it. Write a small .ll analyser that answers the questions engineers ask when reading IR: how many blocks, where control goes, which φ-nodes merge which values, which instructions are used, and where the loops are.

Input

One function in LLVM IR text form:

llvmCopy
Loading…

• Everything after ; on a line is a comment. Blank lines are ignored.
• The define line starts the function (it may carry attributes such as #0 after the parameters); } ends it.
• NAME: starts a block. If the first instruction appears before any label, that block is named entry.
• Every other line is one instruction: either %v = OPCODE ... (defines an SSA value) or OPCODE ... (e.g. store, br, ret, call void ..., unreachable).

Successors (from each block's last instruction)

Output

cCopy
Loading…

• I counts instructions (not labels or comments); V counts instructions that define a % value.
• Blocks in source order; φ lines in source order, pairs in the order written.
• Opcodes sorted alphabetically; the opcode of %v = OP ... is OP (so %r = call i32 @f() is call).
• Back edges: run a depth-first search from the first block, visiting successors in the order listed; an edge to a block that is still on the DFS stack is a back edge. Print them in the order found, or back edges: none.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. A line classifier (define / label / instruction / end) and a tiny operand parser for br and phi.
2. A block table with successor lists, then an iterative or recursive DFS for back edges.

Hidden tests use typical -O0 output (alloca/load/store, an unlabelled entry block, attributes), nested loops, a call returning a value, and an unreachable block.