Summary
Add frontend validation for VMI register types in both PTODSL and TileLang. Invalid VMI register element types should be rejected before generating or lowering PTO/VMI IR, instead of failing later in an MLIR verifier, lowering, code generation, or compilation.
Motivation / use case
PTODSL and TileLang users can currently construct VMI programs with register types that are not legal for VMI. The error is discovered too late, so diagnostics are farther from the source declaration and may surface as a confusing backend failure.
Both frontends should provide the same early and actionable validation behavior. This also prevents PTODSL and TileLang from accepting different type sets for equivalent VMI programs.
Proposed API / behavior
- Define or reuse a single source of truth for the VMI register element types supported by PTOAS, including integer signedness/width, floating-point and low-precision types as applicable.
- Validate VMI register types when PTODSL and TileLang construct or compile VMI values/operations, before IR lowering or code generation.
- Reject an unsupported type with a frontend diagnostic that identifies the offending register/value, the supplied type, and the expected legal type set.
- Apply the validation consistently to explicit register declarations and inferred/result register types.
- Keep the existing IR/backend verifier checks as a defensive fallback.
- Do not change the behavior of programs that use legal VMI register types.
Acceptance criteria
- PTODSL rejects an illegal VMI register type at frontend compile time with an actionable diagnostic.
- TileLang rejects the equivalent illegal type at frontend compile time with an equivalent diagnostic.
- Focused negative tests cover illegal explicit and inferred/result types in both frontends.
- Positive tests confirm representative legal integer, floating-point, and supported low-precision VMI register types remain accepted.
- The legal type definition is shared or otherwise kept centralized so the two frontends cannot silently drift.
Alternatives considered
Relying only on the existing VMI IR verifier or downstream compiler errors preserves correctness, but reports the problem too late and produces a worse frontend user experience.
Summary
Add frontend validation for VMI register types in both PTODSL and TileLang. Invalid VMI register element types should be rejected before generating or lowering PTO/VMI IR, instead of failing later in an MLIR verifier, lowering, code generation, or compilation.
Motivation / use case
PTODSL and TileLang users can currently construct VMI programs with register types that are not legal for VMI. The error is discovered too late, so diagnostics are farther from the source declaration and may surface as a confusing backend failure.
Both frontends should provide the same early and actionable validation behavior. This also prevents PTODSL and TileLang from accepting different type sets for equivalent VMI programs.
Proposed API / behavior
Acceptance criteria
Alternatives considered
Relying only on the existing VMI IR verifier or downstream compiler errors preserves correctness, but reports the problem too late and produces a worse frontend user experience.