test(rocke): pin the llvm23 datalayout m:e mangling spec and complete its support - #10260
Open
shumway wants to merge 1 commit into
Open
test(rocke): pin the llvm23 datalayout m:e mangling spec and complete its support#10260shumway wants to merge 1 commit into
shumway wants to merge 1 commit into
Conversation
llvm23 support (#9583) shipped _DATALAYOUT_LLVM23 as an alias of the llvm22 layout, with a comment to re-derive it on a real LLVM-23 host and split it out if drift was found. On a real LLVM-23 host (ROCm 7.13, AMD clang 23.0.0git) the AMDGPU datalayout includes the ELF symbol-mangling spec `m:e` (e- -> e-m:e-) that LLVM 20/22 omit, so the aliased stub disagrees with what the toolchain emits and the drift guard fails on every wired arch. The stub was harmless at runtime only because the comgr SOURCE path overrides the module datalayout; bitcode input or a stricter verifier would reject it. Split _DATALAYOUT_LLVM23 out from the llvm22 alias with the m:e spec, in lockstep across all three engine mirror sites (python _DATALAYOUT_LLVM23, cpp ROCKE_LL_DATALAYOUT_LLVM23, cpp ROCKE_DATALAYOUT_LLVM23) plus the header, and regenerate the llvm23 golden IR hashes (only llvm23's 79 hashes change; llvm20/llvm22 untouched). Harden the guards so this can't land green again: - Add an always-run host-only test asserting llvm23 == llvm22 + m:e, so an accidental re-alias fails on the bare CI gate rather than only on a ROCm-7.13 box with hipcc. This is the gap that let the stub pass: byte-identity is self-consistent with the stub, and the toolchain drift guard skips without a real LLVM-23 toolchain. - Add an m:e per-flavor pin to the C++ flavor-datalayout SSOT test, mirroring the existing p8 pin, so the new drift axis has the same structural guard. Also correct the datalayout comments: p8 is the buffer-resource address space (128-bit buffer descriptor), not the buffer fat pointer (that is p7), and the LlvmDatalayoutKind docstring now reflects that two fields drift (p8 shape and m:e), with the kind grouping flavors by p8 shape / intrinsic-declare compatibility rather than full datalayout identity. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
✅ All Checks Passed — Ready for Review
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🎉 All checks passed! This PR is ready for review. |
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.
ISSUE ID : AICK-1517
Summary
llvm23 support (#9583) shipped
_DATALAYOUT_LLVM23as an alias of the llvm22 layout, with a comment to re-derive it on a real LLVM-23 host and split it out if drift was found. On a real LLVM-23 host (ROCm 7.13, AMD clang 23.0.0git) the AMDGPU datalayout includes the ELF symbol-mangling specm:e(e-→e-m:e-) that LLVM 20/22 omit, so the aliased stub disagrees with what the toolchain emits and the drift guard fails on every wired arch. The stub was harmless at runtime only because the comgr SOURCE path overrides the module datalayout; bitcode input or a stricter verifier would reject it.Changes
_DATALAYOUT_LLVM23out from the llvm22 alias with them:espec, in lockstep across all three engine mirror sites (_DATALAYOUT_LLVM23,ROCKE_LL_DATALAYOUT_LLVM23,ROCKE_DATALAYOUT_LLVM23) plus the header, and regenerate the llvm23 golden IR hashes (only llvm23's 79 hashes change; llvm20/llvm22 untouched).llvm23 == llvm22 + m:e, so an accidental re-alias fails on the bare CI gate rather than only on a ROCm-7.13 box with hipcc. This is the gap that let the stub land green: byte-identity is self-consistent with the stub, and the toolchain drift guard skips without a real LLVM-23 toolchain.m:eper-flavor pin to the C++ flavor-datalayout SSOT test, mirroring the existing p8 pin, so the new drift axis has the same structural guard.llvm22 + m:erelationship (derived from the llvm22 constant, not a second copy).p8is the buffer-resource address space (128-bit buffer descriptor), not the buffer fat pointer (that isp7); theLlvmDatalayoutKinddocstring now reflects that two fields drift (p8 shape andm:e), with the kind grouping flavors by p8 shape / intrinsic-declare compatibility rather than full datalayout identity.Local validation (real gfx1151, ROCm 7.13 / clang 23)
rocke_enginepybind extension.rocke_flavor_datalayout_ssotm:epin..llbyte-identical, incl. the llvm23m:epath).ROCKE_BACKEND=bothdifferential): 546 passed, 32 skipped (all torch-gated, expected in the torch-free venv).test_datalayout_matches_hipcc_emitted_ir) now passes against the installed toolchain on every wired arch.🤖 Generated with Claude Code