Serem: the target-independent SSA IR

Serem is Sere's own SSA intermediate representation. It sits between the typed AST and LLVM IR, it is fully inspectable as text, and it is defined by Sere's own model — not by an LLVM version. --emit-serem shows it, --backend=serem compiles through it, and the optimizer can rewrite it before either backend runs.

.sere source
    │
    ▼
 TypeChecker (typed AST)
    │
    ├─ IRGenerator ─────────────────► llvm::Module ─┐
    │                                              │
    └─ SeremGenerator ──► Serem IR ─┬─ SeremTransform (opt passes)
                    (--emit-serem)  │
                                    └─ SeremLLVMBackend ──► llvm::Module ─┤
                                                                         ▼
                                                opt pipeline ──► .ll / .s / exe

Everything below the typed AST goes through the same optimization pipeline, so --emit-serem, --emit-llvm, --emit-asm, and a linked executable all agree about which switches are on.

Why a second IR

Text format

The printed form is stable and line oriented. A module is a header, then its type definitions, globals, and functions, in that order.

module @test
type @Exception = %Exception [class, field=message:1]
global @str.0 = str "Hello world!"
func @main() -> i32 {
entry:
  runtime.print @str.0
  return 0
}

Value references:

Type model

IRType is a value type — cheap to copy and compare — with these kinds:

Two helper contracts live next to the types because both the generator and the backend must agree on them without exchanging data out of band:

• ListElementKind — the numeric tag stored with a list so the backend knows its element layout and the runtime formatter knows how to print an element.
• recordTypeId(name) — FNV-1a hash of a record name, stored in the first word of every class value so a union can answer x is Mayor for a member it does not list.

Instruction set

Serem opcodes are strings, so a new operation does not need a new enum value. IRBuilder covers the common shapes; the generator may also emit a dialect-specific opcode directly through operation().

Arithmetic, logic, and values

Aggregates, strings, and runtime calls

Control flow

Exceptions

--no-runtime-checks removes error.enter, error.leave, and error.bind, and rewrites every error.isa to false. The handler blocks then become unreachable and the unreachable-block pass deletes them, so a release build carries no exception machinery at all.

Coroutines and async

Optimization passes

SeremTransform.h defines TransformPass: a named rewrite that reports whether it changed the module. The driver iterates the selected passes to a fixed point (bounded by eight rounds, since every pass is monotone).

Every pass is independent: none of them knows about the others, and adding one means writing a class and putting it in transformPasses() (or in defaultTransformPasses() if it should always run).

Backend

SeremLLVMBackend lowers a Serem module to llvm::Module:

The lowered module then enters the same optimization pipeline as a module produced by IRGenerator, so --backend=serem and the default backend share every optimization switch.

Using it

--no-transformers prints what the generator produced, before any rewrite, which is the right starting point when a pass looks wrong.

Safety notes

• Values are shared pointers. Replacing an operation means rewriting every operand that points at it (that is what applyReplacements does) and then removing it from its block; editing a block in place without doing both leaves the printer and the backend disagreeing.
• A block is a straight-line list of operations plus a terminator flag. Passes that change control flow must keep isTerminated() accurate.
• removeFunction and removeBlock must not run while a walk over the module is in progress; the dead-code pass collects names first and removes second.