[feikou]

Motivation

buffer_load_* ... lds ignores the instruction's immediate offset when computing the LDS destination address in the simulator. Per the CDNA3/CDNA4 ISA reference guides, §9.1.9 "Memory Buffer Load to LDS":

LDS_ADDR = LDSbase + LDS_offset (M0) + inst_offset + (TIDinWave * 4)
MEM_ADDR = Base + mem_offset (soffset) + inst_offset + off_vgpr + stride * (idx_vgpr + TIDinWave)

inst_offset feeds both addresses (LLVM IntrinsicsAMDGPU.td, int_amdgcn_load_to_lds, which also covers buffer fat pointers: "imm offset (applied to both input and LDS address)"). Kernels that set M0 once and issue several buffer_load_dword ... offen offset:0/256/512 lds to fill consecutive LDS tiles therefore kept overwriting the first tile under the simulator.

Technical Details

• lib/python/amdisa/codegen/_generator.py: the MUBUF LDS-load template now sets d->lds_base = wf.m0() + inst_.offset + wf.lds_base(). soffset and the VGPR offset stay memory-side only, matching the formula above.
• Regenerated generated/{cdna1,cdna2,cdna3,cdna4,rdna1,rdna2}/mubuf_exec.cpp (documented python -m amdisa --multi ... --gen-isas flow + clang-format). With the in-tree ISA XMLs the unmodified generator reproduces every checked-in mubuf* file byte-for-byte; the only resulting change is that one line in the 18 buffer_load_* LDS branches per file. gfx1250's *_load_async_to_lds_* (per-lane VGPR LDS address, separate template) and rdna3_5's buffer_load_lds_* stubs (UnimplementedInst) are untouched; rdna3/rdna4 generate no MUBUF LDS-load path.
• tests/amdgpu_vm_test.cpp: MubufLdsTest.LoadDwordLdsAppliesInstOffset (CPU-only, cdna1-4): M0 = 0x200, two encoded buffer_load_dword v1, s[4:7], 0 offen [offset:256] lds from two distinct source rows, all 64 lanes of both LDS rows checked.

Issue Tracking

No existing issue; related: #5747 (workgroup lds_base term on the same path).

Test Plan

• rocjitsu_tests --gtest_filter='MubufLdsTest.*' before and after the generator change.
• python -m pytest lib/python/amdisa/tests and full ctest for regressions.

Test Result

• MubufLdsTest.LoadDwordLdsAppliesInstOffset: on unmodified develop it fails for all four CDNA targets (lane 0: LDS+0x200 reads 0xB0000000 instead of 0xA0000000 because the offset:256 load overwrote row 0; LDS+0x300 still holds the 0xDEADBEEF fill); passes with this change.
• Cross-checked on gfx950 hardware (ROCm 7.2.0) with an equivalent inline-asm kernel: the two rows land at LDS+0 and LDS+256 on hardware; the simulator matches only with this change.
• Full ctest: no status changes versus develop other than the added MubufLdsTest.LoadDwordLdsAppliesInstOffset.
• python -m pytest lib/python/amdisa/tests: 1319 passed, 46 skipped.

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

[therock-pr-bot]

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🔎 pre-commit	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—
🤖 therock-pr-bot	✅ Pass	—

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

[atgutier]

Thanks for the fix!

Everything with the fix to the generator and resulting C++ is in working order.

Can you remove the tests for this PR? We prefer not to grow individual HIP C++ tests per instruction for testing semantics and are currently working on systematically adding more tests for the ISAs.

[feikou]

Done — dropped the HIP test and its CMake registration; kept the in-process MubufLdsTest.LoadDwordLdsAppliesInstOffset in amdgpu_vm_test.cpp (same style as DsTransposeTest). Happy to drop that as well if you'd rather rely on the upcoming ISA test work.