Multi-Level Typed SSA Pipeline

The multi-level typed SSA pipeline splits compiler lowering into four explicit

levels:

HIR -> MIR -> LIR -> MachineIR

The goal is to preserve semantic facts early and introduce target details only

at the documented lowering boundary.

Run the bounded gate with:

make typed-ssa-pipeline-check
make native-ir-check

native-ir-check depends on typed-ssa-pipeline-check, so native IR validation

cannot run without first validating the full IR stack evidence. These gates do

not run self-host, release, deployment, emulator, or broad benchmark jobs.

Evidence Files

• multi-ir/levels.tsv: HIR, MIR, LIR, and MachineIR level definitions.
• multi-ir/metadata-fields.tsv: required metadata for every level.
• multi-ir/lowering-boundaries.tsv: allowed and forbidden lowering

decisions.

• multi-ir/dump-formats.tsv: stable text, TSV, and JSON dump format paths.
• multi-ir/backend-consumption.tsv: backend consumption and transition

evidence.

• multi-ir/diagnostics.tsv: stable verifier diagnostic classes.
• multi-ir/verification-cases.tsv: positive and negative fixture corpus.
• release/multi-ir-verifier-report.tsv: bounded verifier report.
• release/multi-ir-dump-manifest.tsv: stable dump manifest.
• release/multi-ir-backend-transition.tsv: backend transition evidence.

HIR

HIR owns parsed, resolved, and typed source structure. It carries source spans,

symbol ids, type ids, effect sets, and stable textual ids. HIR must not contain

target-specific decisions such as ISA, registers, ABI classes, stack slots,

relocations, or object sections.

MIR

MIR is typed and effect-aware SSA. MIR carries:

• SSA value ids;
• type ids;
• effect sets;
• ownership facts;
• escape facts;
• alias classes;
• alignment;
• hotness;
• source spans.

MIR must stay target-independent. Target leakage in MIR is rejected.

LIR

LIR is the ABI and legal-type boundary. It introduces legal value types, ABI

classes, call conventions, stack slots, and runtime calls. It may record ABI and

runtime decisions, but it must not select target instructions, allocate

registers, define frame layout, emit relocations, or choose object sections.

MachineIR

MachineIR owns target-specific machine lowering: instruction selection,

scheduling, register allocation, frame layout, branch forms, relocations, and

object metadata. MachineIR instructions must carry source spans so diagnostics

and validation can still trace generated code back to source.

Diagnostics

The verifier rejects malformed or unsafe IR evidence with stable diagnostics:

MULTI_IR_SCHEMA
MULTI_IR_TARGET_LEAK
MULTI_IR_SSA
MULTI_IR_LEGAL_TYPE
MULTI_IR_MACHINE_METADATA
MULTI_IR_LOWERING_INVARIANT
MULTI_IR_SPAN

These diagnostics are release-relevant. A backend may not satisfy this pipeline

by redoing frontend decisions or by dropping type, effect, source-span, ABI, or

machine metadata.

Backend Consumption

Backends either consume an appropriate IR level or carry explicit transition

evidence in release/multi-ir-backend-transition.tsv.

Current rows classify:

• native machine code as MachineIR-backed;
• direct ELF as a MachineIR transition path;
• relocatable object emission as a LIR transition path;
• archive/linker input as MachineIR-derived object metadata;
• C compatibility as a HIR transition path that cannot define native

optimization semantics.