IR¶
Accepted
Accepted for V1 shape, verifier-visible categories, and backend-facing lowering obligations. Exact opcode names and dump syntax remain implementation details.
The first IR is a small structured backend-facing representation, not SSA. It exists to decouple semantic analysis from code generation and to give every backend the same input contract.
See Phase Boundaries for the AST/SIR/IR seam contract and SIR, IR, and Lowering for the V1 schema obligations and representative lowering recipes.
IR invariants: - no unresolved names - no unresolved generics or semantic contracts - no source-level method calls - optional debug names and source spans are provenance only, not semantic identity or linkage - type, function, block, local, parameter, value, and instruction IDs are IR-local identities, not reused SIR IDs - public IR dumps are produced from verified IR; malformed IR is reported through deterministic diagnostics instead of dumped as a public contract - no AST or SIR dependencies in backends - deterministic printing - verified before C emission or interpretation
V1 IR concepts include:
- modules, functions, parameters, blocks, locals, constants, and values;
- binary operations, calls, branches, returns, traps, and explicit safety checks;
- target and safety-mode facts needed by lowering and execution;
- optional source provenance such as spans and debug names for diagnostics, deterministic dumps, and debug-friendly generated internal symbols;
- structured blocks and terminators even for single-block functions;
- ABI, export, import, and linkage facts;
- layout, slice-descriptor, ownership-lowering, and dynamic-dispatch facts needed by accepted V1 lowering.
Deferred metadata includes:
- alias/noalias facts;
- fast-math zones;
- broad allocation-effect metadata;
- realtime/kernel restrictions;
- CPU features;
- optimizer hints;
- platform-feature metadata.
A later V1 backlog item may accept a narrow deferred fact when it owns the feature need.
Non-SSA V1¶
The first IR is structured and non-SSA. SSA can be introduced later if optimization needs justify it. V1 needs clear lowering, verification, deterministic dumps, and backend emission more than optimizer infrastructure.
Backend Neutrality¶
Backend boundary
IR must not encode C-only, interpreter-only, or LLVM-only concepts. If backend-specific execution or emission needs information, the shared IR contract should be extended deliberately.
The interpreter backend is another IR consumer. It executes the same verified IR that native backends emit from, which keeps execution tests and comptime evaluation aligned with backend semantics.
Safety Checks and Traps¶
Lowering should make required runtime safety checks explicit in IR when the selected safety mode requires them. Backends and the interpreter should not rediscover mandatory checks from AST or SIR.
Checked safety failures are represented as traps with stable trap kinds. V1 trap kinds include at least:
- signed integer overflow;
- bounds check failure;
- invalid slice range;
- invalid optional unwrap, if unchecked optional unwrapping remains a V1 source form.
Checked traps are not ordinary T!E errors and do not change function signatures. In Unchecked safety mode, lowering may omit dynamic checks whose failure would be illegal behavior for the program.
Verifier¶
IR consumers consume verified IR only. The verifier runs before C emission, runtime interpretation, and comptime interpretation. For demand-driven comptime, the verifier may run on smaller lowered units as they become available.
The initial V1 verifier checks:
- all referenced functions, blocks, locals, parameters, constants, and types exist;
- value uses match declared IR types;
- every block has a valid terminator;
- branch targets exist and receive the expected arguments when block arguments are used;
- functions return values matching their declared return type;
- call targets and arguments match function signatures, including call-convention facts where relevant;
- loads, stores, field access, indexing, and slicing use valid pointer, slice, or aggregate types;
- explicit safety checks guard the operations they protect in structured IR terms;
- trap instructions carry a stable trap kind;
- unresolved names, source-level method calls, semantic contracts, generics, AST IDs, and SIR IDs do not appear in IR;
- source-derived debug names, when present, are not used as identity, verifier facts, linkage names, or operation semantics;
- ABI, export, import, and linkage facts are complete for externally visible declarations;
- IR printing order is deterministic.