Conversation
CHIPUninitializeCallOnce accessed PerThreadDefaultQueue (a thread_local unique_ptr) from an atexit handler. TLS destruction order relative to atexit is implementation-defined; with clang 23 the unique_ptr is already destroyed, causing a SEGFAULT on the dangling pointer. Remove the per-thread queue sync since TLS destruction handles cleanup.
The chipstar OS component in spirv64v1.X-unknown-chipstar triples was added in LLVM 23, so gate HAVE_CLANG_NEW_OFFLOAD_DRIVER on LLVM 23+ instead of 22+. Use conditional RTDEVLIB_TRIPLE variables instead of hardcoded chipstar triples in rtdevlib compilation so LLVM 22 falls back to the plain spirv64 triple.
configure_llvm.sh: support version 23 by cloning from CHIP-SPV/llvm-project and CHIP-SPV/SPIRV-LLVM-Translator (chipStar-llvm-23 branches) with patches pre-applied, skipping the patch application step. New test-llvm23.yml workflow runs on PR and workflow_dispatch with both translator and native variants on Linux (5 test combos) and macOS (PoCL).
Commit 0947b0e fixed two occurrences but missed line 136. LLVM 23 removed Constant::isZeroValue(); use isNullValue() which is equivalent.
The constant_fold_lgamma_r test targets amdgcn-amd-amdhsa and requires ROCm device libraries. It is not applicable to SPIR-V builds and always fails with "cannot find ROCm device library". Exclude it via CTestCustom.cmake.
processOptions() appends per-compilation diagnostics (e.g. the "warning: ignored option" messages for unrecognized flags) to the program log, but it ran inside compile(), which is skipped on an HIPRTC output-cache hit. As a result the program log depended on cache state: the first compilation of a program warned about an ignored option, but a subsequent identical compilation served from cache produced an empty log. TestHiprtcOptions failed on a warm cache for exactly this reason. Hoist option processing into hiprtcCompileProgram ahead of the cache lookup so the diagnostics are recorded on every path, and pass the already-processed options into compile().
The promoteInt validity check converted the post-link bitcode to SPIR-V with llvm-spirv, which isn't built when LLVM uses the in-tree SPIR-V backend (native build). Fall back to 'clang --target=spirv64*-unknown- chipstar -x ir' when llvm-spirv is unavailable, and pass CLANG into the test environment from CMake.
LLVM 23 (current main) removed the LLVM_ENABLE_PROJECTS=openmp build mode, so configuring the fork with "clang;openmp;clang-tools-extra" fails with 'Support for the LLVM_ENABLE_PROJECTS=openmp build mode has been removed'. chipStar does not use OpenMP (no libomp/-fopenmp/OpenMP:: references anywhere), so drop it from the build entirely rather than migrating it to LLVM_ENABLE_RUNTIMES.
The LLVM 23 CI built the separate 'chipStar-llvm-23' fork branch, which had drifted from the LLVM PR (#186972) head 'chipstar-native-spirv' and was missing the rebase onto current main plus the in-tree-backend / llvm-spirv-fallback / RDC fixes. That caused the native (hipDeviceLink RDC: undefined __hip_fatbin) and translator (hipspv-link: -spirv-ext on a host-only LLVM) build failures. Point the LLVM 23 build at 'chipstar-native-spirv' so CI builds the same LLVM as the PR. Validated locally via configure_llvm.sh for both variants (assertions ON): native L0 1174/1174 + OCL 1175/1175 with hipTestDeviceLink passing, translator 1175/1175.
The hip_sycl_interop and hip_sycl_interop_no_buffers samples link their executables with -fsycl using chipStar's clang++ (not Intel's icpx). Starting with LLVM 23 the upstream -fsycl driver makes clang-linker-wrapper inject a dependency on libLLVMSYCL.so, which is only produced by an LLVM build that enables the SYCL project. chipStar builds LLVM with LLVM_ENABLE_PROJECTS="clang;clang-tools-extra" (no SYCL), so the library does not exist and the link fails with: /usr/bin/ld: cannot find libLLVMSYCL.so: No such file or directory Only build these two -fsycl-linked samples on LLVM < 23. The sycl_hip_interop sample (a static library, no -fsycl link) is unaffected and keeps building.
On macOS the new offload driver (default on LLVM 23) crashes clang while building the offload compilation jobs for HIP device code: Assertion failed: (!TargetInitialized && "Target already initialized!"), function setTarget, file Darwin.h, line 453. Building the host (Darwin/arm64) toolchain args for the SPIR-V offload kind re-enters Darwin::AddDeploymentTarget -> setTarget(), which asserts because the target was already initialized. This is an upstream Darwin driver bug in the new offload driver path. Gate HAVE_CLANG_NEW_OFFLOAD_DRIVER on NOT APPLE so macOS falls back to the old offload driver (the same path LLVM 22 uses and which builds fine). This appends --no-offload-new-driver to the HIP compile and RDC link flags via the existing LLVM_VERSION_MAJOR>=23 branches. Linux keeps the new offload driver.
The early-out in HipPrintfToOpenCLPrintfPass treated *any* module with a
single printf use as already-lowered ("only used by _cl_printf"). That is
only true once the pass has created its _cl_print_str helper. A module whose
sole printf call is a genuine, not-yet-lowered call -- e.g. the device-side
__assert_fail printf from spirv_hip.hh, which is the only printf in a kernel
that just uses assert() -- also has exactly one use, so the pass skipped it.
Skipping leaves that printf's format string in a non-constant address space.
The SPIR-V translator must then emit SPV_EXT_relaxed_printf_string_address_space,
which the runtime consumer (IGC on Intel GPUs, the llvm-spirv reverse path on
macOS/pocl) rejects with "InvalidModule ... disabled by --spirv-ext option".
The kernel module fails to load and the assert test hangs (200s timeout).
Only short-circuit when the _cl_print_str helper already exists. With the
helper absent, fall through and lower the printf so its format string ends up
in the constant address space and the extension is no longer required.
Fixes Unit_Assert_Positive_Basic_KernelPass_AssertionTest timing out on
LLVM 21 / 22-native (Linux, Intel Arc B570) and LLVM 22 native/translator
(macOS). Verified end-to-end on a B570: the test now passes and device-side
assert prints its message and aborts correctly.
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.
No description provided.