ptxas 13.0 -O1+ miscompiles unrolled inline-PTX carry chains in a probe kernel; deployed kernel unaffected by parity, root cause open #25
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found while running the #24 go/no-go probe (beast:/tmp/kregs/tcmul.cu). Recording it because the mining kernel from #23 uses the same inline-PTX idiom.
Symptom
A probe kernel does, per thread, 12 independent
v[i] = gf_mul(v[i], DIAG[i])chains in a#pragma unrollloop, iterated.gf_mulis the #23 asm block verbatim (fourmul.wide.u32, carry assembly,mad.lo.cc/madc.hi.ccreduction). Withnvcc -O3 -arch=sm_120(CUDA 13.0):-Xptxas -O0: correct.-Xptxas -O1and above: wrong. So the PTX is right and ptxas's optimiser changes the result.#pragma unroll 1on the element loop: correct.-G: correct.a*b,__umul64hi) and keeping the PTX reduction: correct..regdeclarations inside{}): correct in one kernel context (k_trace, which stores each value) and still wrong in the twin kernel that only stores a checksum at the end. So it is code-shape dependent, and scoped.regnames are not the whole story.Hypothesis, unproven: predicate pressure. Twelve interleaved carry chains need more live carries than the 7 predicate registers, and something in ptxas's predicate spilling or CC-flag tracking goes wrong at -O1+. The deployed kernel's internal layer is also 12 independent multiply-add chains, but interleaved with a long dependent S-box chain.
Why the deployed kernel is believed fine
To do
-Xptxas -O2vs-O3.🤖 Generated with Claude Code
https://claude.ai/code/session_01Ue5ZZm1Hiv5zPnucykKKuF
Post-deploy guard run on beast with the #23 kernel (bench-harness, miner paused): parity OK, 2000/2000 jobs found solutions, all verified against CPU. Each job is a random 32-byte header and random 512-bit start nonce at difficulty 100,000, so that is 2000 full two-permutation hashes compared bit-for-bit with pow_core. The anomaly does not reach the shipped kernel's code shape.
Probe source for the record (also beast:/tmp/kregs/tcmul.cu). Build
nvcc -O3 -arch=sm_120 [-DPROD_TMP|-DPROD_32|-DPROD_C|-DRUNTIME_DIAG] tcmul.cu; run./tcmul tfor the lane-0 trace,./tcmul 1 5for the checksum comparison,./tcmul 1360 2000for timing. CPU reference: the emulation in the #23 PR description reproduces thettrace for lane 0 (seed 17, splitmix as in the file).