[Common] Fix pointer arithmatic to generate correct LDS/STS instructions - #3291
[Common] Fix pointer arithmatic to generate correct LDS/STS instructions#3291kainzhong wants to merge 3 commits into
Conversation
… instructions Signed-off-by: Kaining Zhong <kainingz@nvidia.com>
for more information, see https://pre-commit.ci
Greptile SummaryThe PR preserves shared-memory pointer provenance while retaining the existing alignment behavior.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Reviews (3): Last reviewed commit: "[Common] Fix pointer arithmatic to gener..." | Re-trigger Greptile |
Signed-off-by: Kaining Zhong <kainingz@nvidia.com>
65036c2 to
8fb861f
Compare
|
Vibe coded a benchmark. Looks like the mostly it's a gain or no change on perf numbers except for a few specific shape:
MXFP8 / NVFP4 shared-memory provenance fix -- resultsAligning the dynamic-SHMEM base through an integer (
Summary
Total kernel time over all 180 workloads: cold 21599 -> 20891 us (1.034x), warm 21357 -> 20610 us (1.036x). Worst single workload: cold 0.937x, warm 0.951x. MXFP8 generic quantize kernel
MXFP8 specialized cast-only kernel (bidimensional)
MXFP8 gated (swiglu / geglu) kernel
NVFP4 2D quantize-transpose kernel
Full per-workload numbers (us, pure GPU kernel time)
Patched but not measurableThree further sites carry the identical anti-pattern but cannot be reached, so they are fixed for consistency rather than measured. Leaving them would let the pattern be reintroduced if those paths are ever enabled.
Method
|
Description
The previous MXFP8 dynamic-SMEM alignment code round-tripped the buffer base through
uintptr_tand cast the integer back to a pointer. That breaks the pointer's link to the extern shared object, so the compiler can no longer prove the address is in the shared window and falls back to generic address-space loads/stores (LD.E/ST.E), which resolve the window at runtime.This PR fixes this behavior so compiler is able to generate the correct LDS / STS instructions.
I have a vibe coded demo repro on https://github.com/kainzhong/ADDR_PTR_REPRO which should explain why.
The pointer works this way:
base + (-base & 127)
= base & ~127 + (base & 127) + (-base & 127)
If the last 7 digits of base is 0000000, then (base & 127) + (-base & 127) is 0
Otherwise it will become 1 << 8
TODO: try int instead of uint
Fixes # (issue)
Type of change
Changes
Please list the changes introduced in this PR:
uintptr_t, in which case nvcc loses track of this pointer's semantics and degrade fromld.shared/st.shared(LDS/STS) told.generic/st.generic(LD/ST)Checklist: