Context
The HBM memory simulator currently zero-pads reads that extend past an allocation boundary (_read_flat returns zeros for OOB elements). This behavior was implicitly relied upon by partial-tile loads — e.g., a 100-row descriptor loaded through a 128-row access tile expects the trailing 28 rows to come back as zeros so a mask can neutralize them.
PR #147 accidentally removed this for the gather path, surfaced by #182. Before reverting, we should decide whether zero-padding is the correct contract or just a convenient default.
Questions to resolve
-
Is zero-padding the right semantic for the dataflow scheduler? On real hardware, does reading past an allocation return zeros, trap, or produce undefined data? The simulator should match.
-
Should this apply uniformly to both paths?
- Regular (strided) loads via
_read_flat
- Gather/scatter (block-indexed) loads via
_gather_from / _scatter_into
-
Should OOB stores be silently dropped? _scatter_into currently raises on OOB offsets. The symmetric choice would be to discard OOB writes, but this may mask bugs.
-
Should the behavior be documented as a contract (i.e., kernels may rely on it) or treated as debug-only UB detection (raise on OOB to catch descriptor misconfiguration)?
Proposal
Document the decision in the KTIR spec or simulator design notes, then implement consistently across both paths.
Context
The HBM memory simulator currently zero-pads reads that extend past an allocation boundary (
_read_flatreturns zeros for OOB elements). This behavior was implicitly relied upon by partial-tile loads — e.g., a 100-row descriptor loaded through a 128-row access tile expects the trailing 28 rows to come back as zeros so a mask can neutralize them.PR #147 accidentally removed this for the gather path, surfaced by #182. Before reverting, we should decide whether zero-padding is the correct contract or just a convenient default.
Questions to resolve
Is zero-padding the right semantic for the dataflow scheduler? On real hardware, does reading past an allocation return zeros, trap, or produce undefined data? The simulator should match.
Should this apply uniformly to both paths?
_read_flat_gather_from/_scatter_intoShould OOB stores be silently dropped?
_scatter_intocurrently raises on OOB offsets. The symmetric choice would be to discard OOB writes, but this may mask bugs.Should the behavior be documented as a contract (i.e., kernels may rely on it) or treated as debug-only UB detection (raise on OOB to catch descriptor misconfiguration)?
Proposal
Document the decision in the KTIR spec or simulator design notes, then implement consistently across both paths.