LinxISA v0.57 SIMT Compiler Contract¶
This page is the compiler-facing summary of the canonical v0.57 SIMT kernel
contract.
It does not replace the ISA manual. It collects the rules that a compiler must
target when lowering parallel-loop work into MPAR / MSEQ kernels.
Scope¶
This page applies to canonical programmable VEC kernels:
BSTART.MPARBSTART.MSEQ
It does not define tile-only VPAR / VSEQ authoring policy beyond the shared
body legality and B.TEXT containment rules inherited from the ISA manual.
Core Execution Model¶
Canonical v0.57 SIMT kernels are group-granular divergent kernels.
This means:
- one kernel body is entered per group instance,
- each group has one architectural body PC,
- each group carries one architectural EXEC mask
p, - scalar instructions execute once per group control-flow step,
- vector instructions execute across the active lanes selected by
p, - divergent control flow is represented by explicit changes to
pwithin the group, not by hidden per-lane PCs.
The architecture therefore allows true group-internal divergence, but the mechanism remains explicit and mask-based.
Canonical 1-D Launch Profile¶
The canonical 1-D lowering profile is:
LB0= lanes per groupLB1= group countLB2=1unless a higher-dimensional profile is explicitly selectedlc0= lane index within a grouplc1= group indexlc2= outer group/depth index when used
The canonical logical linear lane index is:
lc0 + lc1 * LB0
Compiler consequence:
- a compiler must not reinterpret
LB0as total logical threads in canonicalv0.57, - any strip-mined or grouped launch must still preserve the canonical meaning
of
LB0andLB1.
Branch And Reconvergence Model¶
Within an MPAR / MSEQ body:
- in-body
b.*,j, and other legal control transfers are group-internal control-flow operations, - targets must remain inside the current body region selected by
B.TEXT, - the current active-lane subset is the current value of
p, - divergent regions are represented by narrowing, restoring, or otherwise
updating
paround the relevant paths, - reconvergence occurs when control reaches a join point and the compiler or runtime restores the intended EXEC mask.
Canonical v0.57 does not require a hidden architectural per-lane PC stack.
The architectural contract is instead:
- one group PC,
- one visible EXEC mask
p, - explicit compiler-visible mask management,
- body-local control-flow containment.
p Contract¶
p is the architectural EXEC mask for canonical MPAR / MSEQ kernels.
Required rules:
V.CMP.* ->pis the normative vector-to-EXEC producer.- Inactive lanes under the current EXEC mask clear their destination bit to
0when producing a newp. B.Z/B.NZin a kernel body test the current value ofp.- Scalar-uniform kernel-body instructions may read and write
pas a group-domain 64-bit value when the operand encoding permits it.
Compiler consequence:
- branch-heavy SIMT lowering may use
pdirectly for mask save/restore, narrowing, widening, and join handling.
Scalar / Vector Domain Rules¶
The existing unified lx64 kernel rule remains in force:
- if any operand names
vt/vu/vm/vn, the instruction executes asv.*, - otherwise it executes as
l.*.
Additional compiler-facing consequences:
- scalar instructions remain group-uniform,
- vector instructions are implicitly masked by
p, - scalar inputs broadcast when consumed by
v.*, - direct
v.* -> scalarwrites remain illegal unless the instruction is an explicitly defined reduction or mask-producing form.
Scratch And .local Policy¶
Canonical compiler-generated SIMT scratch uses .local accesses through TS.
Required rules:
- compiler-generated lane-private state must not alias across active lanes or across distinct groups,
- compiler-generated scratch addressing must include explicit lane/group terms in the emitted address expression when needed for disjointness,
TOremains the canonical output-tile base,TSis the canonical compiler scratch base for autogenerated SIMT state.
This page freezes the base selection, not a single mandatory slot layout. The exact slot layout may evolve, but it must remain:
- disjoint across lanes,
- disjoint across groups,
- reproducible from the emitted address expression,
- documented by the lowering implementation.
MSEQ Versus MPAR¶
Both forms share the same body and divergence model. They differ in ordering and legality expectations:
MSEQis the deterministic ordered form and is always legal for canonical SIMT lowering.MPARis the parallel form and is legal only when the compiler can preserve the architectural memory and live-state rules for the kernel.
Compiler consequence:
MSEQremains the fallback for complex or not-yet-proven-safe kernels,MPARmust be selected by explicit legality, not by optimistic pattern matching.
Relationship To Current Implementation¶
This page is the target contract for compiler and emulator maturation.
Current LLVM and QEMU bring-up paths may still implement a narrower replay-oriented subset. Closing that gap is tracked by:
docs/architecture/v0.57-simt-compiler-contract-plan.mddocs/bringup/SIMT_COMPILER_MATURITY_PLAN.md
Implementation lag does not change the architectural direction frozen here.