fix(k1): planar off on non-AVX2 builds; drop WIP loop; f32 planar in the exactness gate - #1086
Merged
Conversation
…the exactness gate Three user-reported findings against #1079, all real: - planar_on() did not exclude ARM, but matmul_i4p has no NEON arm: on Graviton/RPi/macOS-without-Metal a planar tensor's f32 path degraded to scalar AND changed the FP accumulation order vs the pair kernel's NEON arm — the bit-identical claim only holds where both twins exist. Planar now requires an AVX2 build until a NEON matmul_i4p lands with matching per-lane order. - planarize_i4_row carried a WIP loop computing two unused indices — removed. - the exactness gate now also asserts matmul_i4p == matmul_i4 bitwise (f32, S=3, I=6100 so the pair-layout tail is exercised), gated __AVX2__ — the test asserts the claim exactly where the gate makes it. 2,944 checks, 0 failures locally. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 18, 2026
BColsey
pushed a commit
to BColsey/colibri
that referenced
this pull request
Aug 18, 2026
The dev push CI failed on an AVX-512-VNNI runner: matmul_i4 takes the dot_i4f_avx512 arm there (different accumulation order), while the engine's planar gate deliberately keeps planar OFF on AVX-512F builds (JustVugg#1086) — so the test asserted a claim the engine never makes. The PR run had passed on an AVX2-only runner: runner lottery, not a code change, flipped the result. The f32 comparison is now gated __AVX2__ && !(__AVX512F__&&__AVX512BW__), matching planar_on() to the letter, with a comment telling the story so the next gate change updates both places. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three user-reported findings against #1079 — all verified real, all fixed:
planar_on()did not exclude ARM, butmatmul_i4phas no NEON arm: on a CPU-only ARM box (Graviton, RPi, macOS without Metal) a planar tensor's f32 dispatch degraded to scalar and changed the FP accumulation order vs the pair kernel's NEON arm — so the bit-identical claim only held on AVX2. Planar now requires an AVX2 build, with a comment stating the re-enable condition: a NEONmatmul_i4pwith matching per-lane order.planarize_i4_row(two computed-then-voided indices) — removed.matmul_i4p == matmul_i4bitwise (S=3, I=6100 so the pair-layout tail is exercised), gated__AVX2__— the test asserts the claim exactly where the gate makes it. 2,944 checks, 0 failures locally; the ARM job from ci: ARM oracle job + integer-kernel bit-exactness gate (closes #1081) #1083 keeps holding the integer-kernel bar with NEON live.Credit to the reporter — finding 1 in particular is precisely the class the new ARM job exists for, and the ARM re-enable now has a written condition instead of a silent gap.
🤖 Generated with Claude Code