ByteAddressBuffer alignment: decide wide-vs-scalarized from the alignment promise alone (consistency)

[nv-slang-bot]

Sub-task of #11545 — 4-way decomposition confirmed by @jkwak-work (#11545 (comment)). Slice 2 of 4 (issue point 3).

Make the wide-vs-scalarized lowering decision depend on the promised alignment alone, so a constant and a runtime location with the same alignment lower identically. Today the constant-folded case uses the actual offset while the runtime case uses the promise, so the same source line can emit different instructions depending on whether location constant-folds — the inconsistency #11545 calls out.

Scope

• The wide-vs-scalarized decision becomes a pure predicate driven by the promised alignment, in source/slang/slang-ir-byte-address-legalize.cpp.

Breaking change

Yes — codegen changes on the constant-folded path.

Docs

The "a constant and a runtime location … lower identically" note.

Dependency

After Slice 1 (#11590): trusting the promise for codegen is only sound once a compile-time-constant location is validated against it (41303), otherwise LoadAligned<float4>(20, 16) would silently emit a wide load at the 16-misaligned offset 20.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[nv-slang-bot]

Triage resolution — updated 2026-06-18 (soundness correction after re-verification at current master).

• Status: Triaged → fix in draft PR [2/3] ByteAddressBuffer: decide wide-vs-scalarized + validate the alignment contract #11595 (Closes #11591), held draft. ⚠️ This corrects an earlier version of this comment that called Slice 2 "self-sound under the carried 41303" — re-verification shows that claim was overstated; the placement of diagnostic 41303 is contested (see Verdict). Please do not treat Slice 2 as standalone-self-sound.
• Link: [2/3] ByteAddressBuffer: decide wide-vs-scalarized + validate the alignment contract #11595
• Verdict: The Slice-2 consistency change itself (decide wide-vs-scalarized from the promised alignment alone; isAligned → pure isWideAccessAligned, so constant and runtime location lower identically) is correct and uncontested. The contested point is where 41303 lives ("a compile-time-constant location must be a multiple of alignment"). PR [2/3] ByteAddressBuffer: decide wide-vs-scalarized + validate the alignment contract #11595 carries 41303 inside Slice 2, but verification at current master (a84f48e62, post-[1/3] ByteAddressBuffer: make alignment a compile-time (constexpr) contract #11594) shows that is unsound as a standalone Slice-2 change: the single-argument accessors still forward __naturalStrideOf<T> as the alignment operand (hlsl.meta.slang:489-491; __naturalAlignmentOf does not exist yet — it is Slice 3 / ByteAddressBuffer alignment: power-of-two requirement, scalar-component relaxation, single-arg natural-alignment fix #11592's producer fix), and simplifyIR folds it to a literal before legalization, so at the legalize entry a forwarded natural stride is indistinguishable from an explicit promise. Consequently an in-Slice-2 41303 false-rejects a valid Load3Aligned(16) / LoadAligned<float3>(16) (uint3 stride = 12, so 16 % 12 ≠ 0, even though 16 is fine for the true 4-byte component alignment). PR [2/3] ByteAddressBuffer: decide wide-vs-scalarized + validate the alignment contract #11595 currently sidesteps this by re-expressing those valid calls (e.g. Load3Aligned(16) → Load3Aligned(16, 4)), which masks the false-positive rather than fixing the producer.
• Next-action — design flag AppVeyor: try to produce a better build version #1 (41303 ownership), @jkwak-work's call. Two coherent resolutions; this is a decomposition-sequencing decision:
  • (A) Defer 41303 to Slice 3 (ByteAddressBuffer alignment: power-of-two requirement, scalar-component relaxation, single-arg natural-alignment fix #11592): make Slice 2 a pure consistency change that depends on Slice 3; Slice 3's __naturalStrideOf→__naturalAlignmentOf producer fix makes the forwarded value a real power-of-two alignment, so 41303 stops false-rejecting. This was the IR-dump-proven triage ruling on 2026-06-13 and was re-verified still valid at HEAD today. Cost: Slice 2 is not self-sound for the explicit LoadAligned<float4>(20, 16) miscompile until Slice 3 lands, so Slice 2 must not merge before Slice 3.
  • (B) Keep 41303 in Slice 2: accepts that valid 3-component single-arg loads must add an explicit alignment (the masking above); contradicts the "fix the producer, don't mask" methodology.
    Recommended: (A) — there is no IR-level marker to scope 41303 to explicit promises only, so a clean Slice-2-only 41303 is not available.
• Blocker: the 41303-placement decision above. PR stays draft (not auto-merged); reviewer + CI in flight.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[jhelferty-nv]

@jkwak-work Handing to you since you own #11545