Require numerical proof for DeepSeek PTO kernels - #157
Conversation
The DeepSeek benchmark surface now uses scalar-reference and invariant oracles instead of presence-only smoke checks. Pin the PTO and LLVM revisions that add machine-readable coverage accounting, host quantization oracles, current tile memory wrappers, and legal narrow floating memory lowering. Constraint: Verification scope is the 43 public DeepSeek APIs and 32 kernel-reachable PTO operations within the frozen 111-operation v0.57 catalog; pyCircuit and LinxCore remain outside this closure. Rejected: Treat declaration or assembly presence as executable semantic coverage | it does not prove numerical behavior. Confidence: high Scope-risk: moderate Directive: Do not report 32/32 kernel-reachable coverage as 111/111 catalog semantic coverage. Tested: clean LLVM clang/lld/llc build and f16-bf16-memory FileCheck; clean PTO 6/6 host CTests; DeepSeek 43/43 API and 32/32 reachable-op contracts; clean QEMU deepseek_tilekernels, pto_parity, and tile suites. Not-tested: repository-wide attention catalog requiring unsupported custom launch/vector-spill lowering; pre-existing v057-tile-phi-edge-tmov ambiguous-join test.
The PTO and LLVM changes were squash-merged upstream, so repoint the superproject from the obsolete topic commits to the corresponding main revisions. The merged and topic revisions have identical Git trees. Constraint: pyCircuit and LinxCore remain outside this closure and are not repinned. Rejected: Retain topic-branch gitlinks | squash merge rewrote both commit identities. Confidence: high Scope-risk: narrow Directive: Preserve the 43-API and 32 kernel-reachable operation verification denominator when interpreting this closure. Tested: merged-vs-topic Git tree identity; 6/6 PTO host CTests; 43/43 API and 32/32 reachable-operation assembly contracts. Not-tested: full 111-operation executable semantics and repository-wide attention catalog lowering.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds comprehensive test coverage and oracle verification assertions for various DeepSeek tile kernels (including MoE, quantization, engram, and MHC) in 17_deepseek_tilekernels.cpp, alongside updating the compiler/llvm and workloads/pto_kernels submodules. The review feedback identifies a type and stride mismatch in the deepseek_engram_hash_i32 test, where an int64_t array is cast and processed as 32-bit elements, which reduces test coverage. A suggestion is provided to use a 32-bit integer array instead.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| deepseek_engram_hash_i32(i1, l0, kElements, 1, kCols, | ||
| 0x12345678u); | ||
| for (int i = 0; i < kElements; ++i) | ||
| const uint32_t *hash_input = reinterpret_cast<const uint32_t *>(l0); | ||
| for (int i = 0; i < kElements; ++i) { | ||
| uint32_t expected = hash_input[i] ^ 0x12345678u; |
There was a problem hiding this comment.
There is a type and stride mismatch between the test input l0 and the oracle verification for deepseek_engram_hash_i32.
l0 is defined as an int64_t array and initialized with 64-bit values (l0[i] = static_cast<int64_t>(i + 1)). However, the oracle casts l0 to const uint32_t * and hashes it as 32-bit elements.
On little-endian systems, this means that for every odd index i, hash_input[i] reads the upper 32 bits of l0[i/2], which is always 0. This significantly reduces the test coverage (half of the inputs are 0) and indicates that deepseek_engram_hash_i32 is likely designed to process 32-bit integers (int32_t / uint32_t).
To fix this and ensure proper test coverage, we should pass a 32-bit integer array (such as i0, which is already initialized with i % kCols) instead of l0.
| deepseek_engram_hash_i32(i1, l0, kElements, 1, kCols, | |
| 0x12345678u); | |
| for (int i = 0; i < kElements; ++i) | |
| const uint32_t *hash_input = reinterpret_cast<const uint32_t *>(l0); | |
| for (int i = 0; i < kElements; ++i) { | |
| uint32_t expected = hash_input[i] ^ 0x12345678u; | |
| deepseek_engram_hash_i32(i1, reinterpret_cast<const int64_t *>(i0), kElements, 1, kCols, | |
| 0x12345678u); | |
| for (int i = 0; i < kElements; ++i) { | |
| uint32_t expected = static_cast<uint32_t>(i0[i]) ^ 0x12345678u; |
1 participant
Summary
Verification
The frozen v0.57 catalog contains 111 operations. This PR claims complete verification of the DeepSeek kernel-reachable 32-operation surface, not 111/111 executable semantics.