feat: cross-compile & upgrade LLVM to 21.1.8#390
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds cross-compilation support across CI and build tooling: new target triples in GitHub Actions, propagation of Changes
Sequence DiagramsequenceDiagram
participant User
participant CI as CI Runner
participant CMake
participant Toolchain as cmake/toolchain.cmake
participant SetupLLVM as setup-llvm.py
participant Builder as Build (cmake/ninja)
User->>CI: trigger workflow (matrix may set target_triple)
CI->>CMake: run cmake -B build/release ... (-DCLICE_TARGET_TRIPLE=TRIPLE)?
CMake->>Toolchain: read CLICE_TARGET_TRIPLE
Toolchain->>Toolchain: configure system name / processor / compiler target / sysroot
CMake->>SetupLLVM: setup_llvm(... --target-platform=PLATFORM?)
SetupLLVM->>SetupLLVM: select artifact manifest for PLATFORM
CMake->>Builder: cmake --build build/release
Builder->>CI: produce build artifact
CI->>CI: run native or cross prune/apply/upload steps (gated by matrix)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/build-llvm.yml (1)
171-216:⚠️ Potential issue | 🟠 MajorMake the prune manifest producer a separate job.
The
+LTOlegs downloadllvm-pruned-libs-${{ matrix.os }}from the samegithub.run_id, but sibling matrix legs have no ordering guarantee. If a consumer leg reachesapplybefore the nativeRelWithDebInfo/OFFleg uploads its artifact, this becomes a flaky CI failure.
🧹 Nitpick comments (3)
config/llvm-manifest.json (1)
1-1: Empty manifest will block builds until regenerated.The manifest is intentionally cleared for the LLVM 21.1.8 upgrade. However, until
build-llvm.ymlandupload-llvm.ymlare run to regenerate artifacts, any build that doesn't have a pre-existing LLVM install will fail inpick_artifact()with "No matching LLVM artifact in manifest".Ensure the follow-up actions (run
build-llvm.yml→upload-llvm.yml) are executed promptly after merging to restore build functionality.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@config/llvm-manifest.json` at line 1, The LLVM manifest file was cleared for the 21.1.8 upgrade which leaves pick_artifact() unable to find artifacts and will block builds; after merging, immediately run the build workflow (build-llvm.yml) to produce artifacts and then run the upload workflow (upload-llvm.yml) to update config/llvm-manifest.json so pick_artifact() can locate matches; verify the manifest is populated and that pick_artifact() succeeds in CI before closing the change..github/workflows/build-llvm.yml (2)
226-235: Fail fast on unsupported target triples.Right now a typo or future triple addition leaves
ARCH/PLATFORM/TOOLCHAINunset and still produces a malformed artifact name.Suggested hardening
if [[ -n "${{ matrix.target_triple }}" ]]; then case "${{ matrix.target_triple }}" in x86_64-apple-darwin) ARCH="x64"; PLATFORM="macos"; TOOLCHAIN="clang" ;; aarch64-linux-gnu) ARCH="aarch64"; PLATFORM="linux"; TOOLCHAIN="gnu" ;; aarch64-pc-windows-msvc) ARCH="aarch64"; PLATFORM="windows"; TOOLCHAIN="msvc" ;; + *) + echo "Unsupported target triple: ${{ matrix.target_triple }}" >&2 + exit 1 ;; esac else🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-llvm.yml around lines 226 - 235, The case block that sets ARCH/PLATFORM/TOOLCHAIN for matrix.target_triple can leave those variables unset for typos or unknown triples; add a default/fallback case in the case statement (for the block handling "${{ matrix.target_triple }}") that logs an explicit error mentioning the unrecognized target triple and exits non‑zero, and also after the case ensure a guard that checks ARCH/PLATFORM/TOOLCHAIN are set (e.g., test -n "$ARCH" && ...) to fail fast; update references to ARCH/PLATFORM/TOOLCHAIN in the surrounding script to rely on this explicit failure rather than producing malformed artifact names.
198-216: Please validate cross-target pruning before packaging.These legs apply a manifest learned from the native arch and then upload immediately, but they never build a cross-target consumer against the pruned install. If the required LLVM library closure differs by target triple, this workflow can publish a broken archive without noticing. A per-target manifest or a small post-prune link smoke test would make this much safer.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-llvm.yml around lines 198 - 216, The workflow applies a native ARCH manifest using the step named "Apply pruned-libs manifest (cross-compile + LTO)" (which calls scripts/prune-llvm-bin.py with MANIFEST="pruned-libs-${{ matrix.os }}.json") but never verifies the pruned install for the cross-target; add a validation step after running prune-llvm-bin.py and before uploading the GH artifact "llvm-pruned-libs-${{ matrix.os }}" that either (a) generates a per-target manifest by running the pruning script on the target toolchain/headers, or (b) performs a small smoke/link test that compiles and links a minimal program against the pruned install at .llvm/build-install/lib (using the matrix.target_triple and matrix.os environment) to ensure all required libraries are present; implement the smoke test as a new step that returns non-zero on failure so the job fails before publishing the artifact.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pixi.toml`:
- Line 43: The change added a new workspace constraint sysroot_linux-aarch64 =
"==2.17" in pixi.toml but the pixi.lock file is now out of sync; regenerate the
lock and commit it by running `pixi lock` locally (or in CI), verify the updated
pixi.lock contains the new sysroot_linux-aarch64 entry, and include the updated
pixi.lock in the commit so the pipeline no longer fails.
---
Nitpick comments:
In @.github/workflows/build-llvm.yml:
- Around line 226-235: The case block that sets ARCH/PLATFORM/TOOLCHAIN for
matrix.target_triple can leave those variables unset for typos or unknown
triples; add a default/fallback case in the case statement (for the block
handling "${{ matrix.target_triple }}") that logs an explicit error mentioning
the unrecognized target triple and exits non‑zero, and also after the case
ensure a guard that checks ARCH/PLATFORM/TOOLCHAIN are set (e.g., test -n
"$ARCH" && ...) to fail fast; update references to ARCH/PLATFORM/TOOLCHAIN in
the surrounding script to rely on this explicit failure rather than producing
malformed artifact names.
- Around line 198-216: The workflow applies a native ARCH manifest using the
step named "Apply pruned-libs manifest (cross-compile + LTO)" (which calls
scripts/prune-llvm-bin.py with MANIFEST="pruned-libs-${{ matrix.os }}.json") but
never verifies the pruned install for the cross-target; add a validation step
after running prune-llvm-bin.py and before uploading the GH artifact
"llvm-pruned-libs-${{ matrix.os }}" that either (a) generates a per-target
manifest by running the pruning script on the target toolchain/headers, or (b)
performs a small smoke/link test that compiles and links a minimal program
against the pruned install at .llvm/build-install/lib (using the
matrix.target_triple and matrix.os environment) to ensure all required libraries
are present; implement the smoke test as a new step that returns non-zero on
failure so the job fails before publishing the artifact.
In `@config/llvm-manifest.json`:
- Line 1: The LLVM manifest file was cleared for the 21.1.8 upgrade which leaves
pick_artifact() unable to find artifacts and will block builds; after merging,
immediately run the build workflow (build-llvm.yml) to produce artifacts and
then run the upload workflow (upload-llvm.yml) to update
config/llvm-manifest.json so pick_artifact() can locate matches; verify the
manifest is populated and that pick_artifact() succeeds in CI before closing the
change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: fbdf875e-89a4-43b2-98a1-39a2520a9284
📒 Files selected for processing (9)
.github/workflows/build-llvm.yml.github/workflows/publish-clice.ymlcmake/llvm.cmakecmake/package.cmakecmake/toolchain.cmakeconfig/llvm-manifest.jsonpixi.tomlscripts/build-llvm.pyscripts/setup-llvm.py
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/build-llvm.yml (1)
224-246: Consider adding a fallback case for unknown target triples.The
casestatement handles the three expected target triples but lacks a default case. If a new target triple is added to the matrix without updating this packaging block,ARCH,PLATFORM, andTOOLCHAINwould remain unset, causing a confusing packaging failure downstream.🛡️ Proposed fix to add a fallback case
case "${{ matrix.target_triple }}" in x86_64-apple-darwin) ARCH="x64"; PLATFORM="macos"; TOOLCHAIN="clang" ;; aarch64-linux-gnu) ARCH="aarch64"; PLATFORM="linux"; TOOLCHAIN="gnu" ;; aarch64-pc-windows-msvc) ARCH="aarch64"; PLATFORM="windows"; TOOLCHAIN="msvc" ;; + *) + echo "Error: Unknown target triple '${{ matrix.target_triple }}'" + exit 1 ;; esac🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-llvm.yml around lines 224 - 246, The case handling for "${{ matrix.target_triple }}" can leave ARCH/PLATFORM/TOOLCHAIN unset for unknown triples; add a fallback branch (the *) in that case statement to either set sensible defaults (e.g., ARCH="x64", PLATFORM="linux", TOOLCHAIN="gnu") or emit a clear error and exit, and include a warning message that shows the unrecognized "${{ matrix.target_triple }}" so downstream packaging doesn't run with empty variables.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/build-llvm.yml:
- Around line 224-246: The case handling for "${{ matrix.target_triple }}" can
leave ARCH/PLATFORM/TOOLCHAIN unset for unknown triples; add a fallback branch
(the *) in that case statement to either set sensible defaults (e.g.,
ARCH="x64", PLATFORM="linux", TOOLCHAIN="gnu") or emit a clear error and exit,
and include a warning message that shows the unrecognized "${{
matrix.target_triple }}" so downstream packaging doesn't run with empty
variables.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 450a2b15-6fee-4107-bda9-0c147c4c5182
📒 Files selected for processing (1)
.github/workflows/build-llvm.yml
Add CLICE_TARGET_TRIPLE to toolchain.cmake for cross-compilation. Upgrade LLVM from 21.1.4 to 21.1.8 and switch publish workflow from xmake to CMake. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Create three dedicated environments (cross-macos-x64, cross-linux-aarch64, cross-windows-arm64) instead of mixing cross-compile deps into the native build environment. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LLVM_USE_SANITIZER=Address is not supported on Windows. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The toolchain.cmake already sets the correct linker (lld-link on Windows, lld elsewhere). LLVM's HandleLLVMOptions.cmake was adding a conflicting -fuse-ld=lld on top of the toolchain's -fuse-ld=lld-link, causing link failures on Windows LTO builds. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LLVM's HandleLLVMOptions generates MSVC-style linker flags (/opt:lldlto, /lldltocache) when LTO is enabled. These are interpreted as file paths by the clang++ GNU driver. Explicitly setting LLVM_USE_LINKER=lld-link tells LLVM's CMake to use the correct flag style. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
clang++ (GNU driver) cannot handle MSVC-style linker flags like /lldltocache: and /opt:lldlto= that LLVM's CMake generates when LTO is enabled. Switch to clang-cl (MSVC driver) on Windows which natively understands these flags. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The package pixi environment doesn't include uv, causing 'uv: command not found' when running integration tests. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add llvm_version and skip_upload inputs to build-llvm workflow - Add upload job to auto-publish artifacts to clice-llvm repo - Add update-clice job to auto-create PR with version bump - Extract distribution components list to scripts/llvm-components.json - Add validate-llvm-components.py to catch stale/renamed components - Add update-llvm-version.py to update manifest and package.cmake Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
510693d to
db37b30
Compare
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
LLVM 21.1.8 changed clang-resource-headers from add_custom_target to add_library(... INTERFACE ...). Add add_library pattern to header scanning so the validation script can detect it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Allow uploading artifacts to clice-llvm without creating a PR to update the clice repo. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add architecture (x64/arm64) field to manifest entries so that pick_artifact can correctly select the right artifact when multiple architectures exist for the same platform. Update setup-llvm.py with --target-arch argument and cmake/llvm.cmake to pass it from CLICE_TARGET_TRIPLE. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Revert to 21.1.4+r1 for this PR (version upgrade should come via the automated workflow). Add missing Windows Debug entry to build-llvm matrix. Manifest now includes arch field for all entries. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Update LLVM from 21.1.4+r1 to 21.1.8 - Add cross-compile build targets to test-cmake.yml: macOS x64, Linux arm64, Windows arm64 - Cross-compile jobs build only (no tests) - Windows Debug artifact pending from build-llvm workflow Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
GitHub Actions include with cartesian product doesn't create new entries - switch to explicit include-only matrix. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When cross-compiling, the built flatc is for the target architecture and cannot run on the host. Use find_program to locate a host flatc instead. Add flatbuffers conda package to provide it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The flatc version must match the FetchContent flatbuffers library version (v25.9.23) to avoid schema_generated.h compatibility errors. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
clang-cl's -fsanitize=address is incompatible with -MDd (dynamic debug CRT). Skip ASAN on Windows and remove -asan suffix from the Windows Debug artifact name. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On Windows, build-llvm.py uses clang-cl directly instead of the toolchain file, so CLICE_TARGET_TRIPLE wasn't setting the compiler target. Pass --target=<triple> via CMAKE_C/CXX_FLAGS and set LLVM_HOST_TRIPLE for correct cross-compilation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When cross-compiling LLVM (Linux aarch64 from x64, Windows ARM64 from x64), tablegen tools are compiled for the target architecture but must run on the host during the build. Add a two-stage build: first compile native llvm-tblgen, llvm-min-tblgen, and clang-tblgen, then pass LLVM_NATIVE_TOOL_DIR to the cross-compile build. macOS cross-compilation is excluded because Rosetta 2 transparently runs x86_64 tools on ARM64 hosts. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The BLAKE3 SSE2 assembly file requires MASM (ml64.exe) which may not be available on Windows CI runners. Since native tools only need tablegen executables, disable assembly files to avoid the dependency. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ailures Remove Windows Debug from the build matrix — clice cannot link against it yet (_ITERATOR_DEBUG_LEVEL mismatch), and the failure blocks the upload job from running. Change the upload job condition to !cancelled() so that flaky post-step failures (e.g. Post Setup Pixi) do not prevent artifact upload. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
All 14 LLVM artifacts successfully rebuilt with cross-compilation support for Linux aarch64 and Windows ARM64. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Remove Windows Debug from CI matrix (known linker mismatch, deferred) - macOS x86_64 cross-compile: enable tests via Rosetta 2 - Linux aarch64 cross-compile: enable tests via QEMU user-mode emulation - Windows ARM64 cross-compile: build-only (no ARM64 emulation on x64) Cross-compiled test binaries run transparently through binfmt_misc (QEMU on Linux, Rosetta on macOS). Tests are compiled with CLICE_ENABLE_TEST=ON for testable platforms. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace cross-compile + build-only with a native build on windows-11-arm runner. This allows running full tests (unit, integration, smoke) on ARM64 Windows. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The pixi-managed clang on windows-11-arm is an x64 binary running under emulation, defaulting to x64 code generation. Pass CLICE_TARGET_TRIPLE so it generates ARM64 code that matches the ARM64 LLVM libraries. Tests still run natively on the ARM64 runner. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace cross-compilation with native runners: - macOS x86_64: macos-13 (Intel) instead of Rosetta on macos-15 - Linux aarch64: ubuntu-24.04-arm instead of QEMU on ubuntu-24.04 - Windows ARM64: windows-11-arm (kept from previous commit) Remove QEMU setup step and build_only logic since all platforms now build and test natively. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
macos-13 runner is no longer available and ubuntu-24.04-arm lacks pixi linux-aarch64 platform packages. Revert these two to the proven cross-compile approach (Rosetta / QEMU). Keep windows-11-arm native runner which works. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…transfer Cross-compile on pixi-supported platforms, upload binaries, then run tests on native runners (macos-15-intel, ubuntu-24.04-arm) instead of QEMU/Rosetta. Add test-run pixi environment for lightweight test-only platform support. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Use cross-linux-aarch64 pixi env for Linux aarch64 cross-compilation (provides sysroot, fixes Exec format error on native ARM64 runner) - Upload lib/ directory alongside bin/ (clang resource dir needed by tests) - Remove unnecessary platform restrictions from build/format features Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…tforms - Add win-arm64 to pixi platforms (6 total) - Move Windows ARM64 from native build to cross-compile from windows-2025 - All 3 new platforms (macOS x64, Linux aarch64, Windows ARM64) use the same pattern: cross-compile on original platform, test on native runner - Move flatbuffers from workspace deps to build feature (unavailable on win-arm64) - Add platform restrictions for build/format/node features (native tools like cmake, ruff, pnpm unavailable on win-arm64) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…error Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The regex `^aarch64-.*-linux` requires a vendor segment between arch and os (e.g. aarch64-unknown-linux-gnu) but the triple `aarch64-linux-gnu` has no vendor. Change to `^aarch64-.*linux` to match both forms. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Conda's ld_impl_linux-64 sets LIBRARY_PATH=$CONDA_PREFIX/lib which contains x86_64 libgcc_s.so.1. When cross-compiling for aarch64, lld finds this incompatible library and fails. Add activation script to clear LIBRARY_PATH in the cross-linux-aarch64 environment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Pixi's activation script `unset` doesn't propagate through its environment capture mechanism. Use `env -u LIBRARY_PATH` to strip the host x86_64 library path directly before cmake invocation, preventing lld from finding incompatible libgcc_s.so.1. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Conda's cross-compilation toolchain sets LDFLAGS with -L$CONDA_PREFIX/lib pointing to host x86_64 libraries. CMake picks up LDFLAGS from the environment, causing lld to find incompatible libgcc_s.so.1. Strip all conda compiler flags since our toolchain.cmake provides the correct settings. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- build-llvm.py: clear LDFLAGS/CFLAGS/LIBRARY_PATH when cross-compiling to prevent conda's host-platform flags from leaking into the target build - build-llvm.yml: use cross-linux-aarch64/cross-windows-arm64 pixi envs for cross-compile jobs (provides aarch64 sysroot) - build-llvm.yml: add "Build clice" step for cross-compiled LLVM to catch architecture mismatches early - build-llvm.yml: add binary architecture verification step Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous 21.1.8 release contained x86_64 objects in the aarch64 package. After rebuilding with proper cross-compilation sysroot and env var isolation, update the manifest with correct hashes. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On macOS runners without upstream clang in PATH, clice falls back to /usr/bin/clang++ (Apple's) which emits vendor-specific flags that upstream LLVM 21 cannot parse, causing 28 unit test failures on macos-15-intel. Add clang/clangxx to the test feature for macOS platforms so test-run gets upstream clang. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Integration tests use CMake with toolchain.cmake which requires -fuse-ld=lld. Without lld in the test-run environment, CMake's compiler check fails on macOS cross-compile test runners. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
CLICE_TARGET_TRIPLEtotoolchain.cmakefor cross-compilation (macOS x64, Linux arm64, Windows arm64)build-llvm.yml(2 per new platform: RelWithDebInfo ± LTO)publish-clice.ymlfrom xmake to CMake withCLICE_RELEASE=ONsysroot_linux-aarch64to pixi.toml for Linux arm64 cross-compileNew platforms
x86_64-apple-darwinaarch64-linux-gnuaarch64-pc-windows-msvcFollow-up
build-llvm.ymlto produce LLVM 21.1.8 artifacts for all 6 platformsupload-llvm.ymlto generate new manifest🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Chores