knowledge: GCC as the intrinsic-spec reference (3-layer drill-down) - #260
Conversation
…down)
The reference used across the NEON/aarch64/wasm planning work was never
written down. A sweep of every URL host in every .md/.rs/.toml found no
intrinsic or ISA reference at all — only four bare "Intel Intrinsics
Guide" mentions with no link, and one GCC file cited off mutable master.
Records gcc-mirror/gcc at a pinned SHA, and the three layers that make it
a full spec surface: config/*intrin.h + arm_neon.h (intrinsic -> builtin),
config/*/*.md (builtin -> instruction + encodings), and testsuite/
gcc.target/* (executable per-intrinsic oracle with inline scalar
reference). Worked example: _mm256_mul_epu32 vs _mm256_mul_epi32 have
identical __v8si signatures, so the type system cannot catch a mix-up;
avx2-vpmuludq-2.c states the even-lane widening semantics as runnable
code.
Also appended (never rewriting prior text):
- agnostic-surface-cpu-matrix.md section M: corrects "authoritative" —
GCC is the fill-in for what could not be executed. Validation of record
is scripts/{neon,wasm}-parity.sh under qemu/node; runtime detection is
sysctl/getauxval/cpuid; GCC supplies per-core feature membership, which
neither of those can give.
- vertical-simd-consumer-contract.md: sourcing note over the four
unlinked Intel Intrinsics Guide citations.
Documented limits, each verified: testsuite filenames are not guessable;
the GitHub API is scoped to session repos; GitHub code search EXCLUDES
FORKS and silently returns 0 for files that demonstrably exist in this
org's forks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdfbkUCBbtZhy3yjSfCDHp
|
Warning Review limit reached
Next review available in: 36 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_901af04d-bd71-4972-a991-2e866dcff85b) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e6bce13731
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| > `qemu-aarch64-static`, asserting every `ndarray::simd` NEON lane is | ||
| > bit-identical to its scalar reference; `scripts/wasm-parity.sh` is the |
There was a problem hiding this comment.
crates/neon-simd-parity/src/main.rs::selfcheck only checks U32x16, F32x16, and I8x16, and only a small subset of their operations; exported NEON lanes such as I16x8, U8x16, and U64x2 are not exercised. Describing the harness as asserting every NEON lane and as the measurement of record can cause later SIMD audits to treat untested lowerings as verified, so document the exact coverage or expand the harness.
Useful? React with 👍 / 👎.
| |---|---|---| | ||
| | **1. declarations** | `gcc/config/i386/*intrin.h`<br>`gcc/config/aarch64/arm_neon.h` | *What builtin does this intrinsic map to, and what are its exact C types?* | | ||
| | **2. machine description** | `gcc/config/*/*.md` | *What instruction / RTL does that builtin lower to, and what are the bit encodings?* | | ||
| | **3. conformance tests** | `gcc/testsuite/gcc.target/{i386,aarch64,arm,...}/` | *What does it compute?* — an executable test per intrinsic with an **inline scalar reference implementation** | |
There was a problem hiding this comment.
The gcc.target directories mix runtime tests with compile-only, diagnostic, and code-generation tests, and GCC does not provide an executable inline scalar reference for every intrinsic. Presenting this as a guaranteed per-intrinsic oracle makes the documented workflow fail or falsely imply semantic validation whenever only a compile/scan test exists; qualify this as a useful source when such a runtime reference test is available and retain an ISA specification as the fallback.
Useful? React with 👍 / 👎.
…dex P2 x2) - agnostic-surface-cpu-matrix.md §M: the neon/wasm parity harness does not assert "every NEON lane" — selfcheck covers exactly U32x16 (ARX triple), F32x16 (splat/roundtrip/add/reduce_sum), and I8x16 (roundtrip/add). Named the exact coverage, marked unexercised exported lanes (I16x8, U8x16, U64x2) as unverified-by-this-harness, and stated that extending selfcheck is the promotion path. - gcc-intrinsic-spec-reference.md layer 3: gcc.target mixes runtime tests with compile-only/diagnostic/scan-assembler tests, so it is a per-intrinsic oracle only where a dg-do run test with a scalar reference exists. Documented the dg-do discriminator and the ISA-spec fallback for the compile-only case. Both were the same defect this doc set exists to prevent: a true statement about a mechanism widened into a universal claim about coverage.
2 participants
Knowledge-only, +141 lines, no code. Records the spec-reference workflow used in the #256/#257/#258 arc so the next SIMD-semantics question doesn't re-derive it.
.claude/knowledge/gcc-intrinsic-spec-reference.md(new) — GCC (gcc-mirror/gcc, pinned SHA8f16982) as the three-layer intrinsic spec:config/*intrin.h+arm_neon.h(intrinsic → builtin),config/*/*.mdmachine descriptions (builtin → instruction/encoding),gcc/testsuite/gcc.target/*(executable per-intrinsic oracle with inline scalar reference). Worked example:_mm256_mul_epu32vs_mm256_mul_epi32(identical signatures, even-lane widening, signed/unsigned extension the only difference). Includes documented limits — notably that GitHub code search excludes forks, which produced a false "not found anywhere in the org" earlier in the arc..claude/knowledge/agnostic-surface-cpu-matrix.md§M — scope correction separating what we validate live (qemu/node parity), what runtime detection covers (sysctl/getauxval/cpuid), and GCC's actual role: the fill-in for silicon we can't test, not the authority over what we measured..claude/knowledge/vertical-simd-consumer-contract.md— sourcing note above the four previously-unlinked Intel Intrinsics Guide citations.Generated by Claude Code