Repository navigation
JIRA ID : LCOMPILER-876 : Remove calls to hipconfig in all of rocm-libraries: read ROCm version from .info/version - #7235
Merged
Conversation
david-salinas
marked this pull request as draft
May 9, 2026 02:52
github-actions
Bot
added
project: hipblaslt
project: hipsparselt
ci:hipsparselt-fast
labels
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #7235 +/- ##
============================================
- Coverage 72.37% 66.00% -6.37%
============================================
Files 2879 691 -2188
Lines 478175 202565 -275610
Branches 70864 28533 -42331
============================================
- Hits 346073 133699 -212374
+ Misses 108153 59996 -48157
+ Partials 23949 8870 -15079
🚀 New features to boost your workflow:
|
david-salinas
force-pushed
the
users/dsalinas/deprecate-hipcc
branch
2 times, most recently
from
May 9, 2026 18:57
a9b4e58 to
ed46cb6
Compare
1 task
lamb-j
marked this pull request as ready for review
May 28, 2026 02:11
accauble
marked this pull request as draft
June 9, 2026 16:23
accauble
force-pushed
the
users/dsalinas/deprecate-hipcc
branch
from
June 9, 2026 16:47
d01bb1e to
3a93b4c
Compare
Contributor
|
This pull request has been inactive for 25 days and will be marked as stale. If you would like to keep this PR open, please:
This PR will be automatically closed in 5 days if no further activity occurs. |
Contributor
|
This pull request has been automatically closed due to inactivity (30 days with no updates). If you'd like to continue working on this, feel free to reopen the PR or create a new one. |
✅ 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. |
3 of 4 tasks
david-salinas
force-pushed
the
users/dsalinas/deprecate-hipcc
branch
from
August 7, 2026 21:57
44398db to
90c19fb
Compare
david-salinas
force-pushed
the
users/dsalinas/deprecate-hipcc
branch
from
August 10, 2026 20:51
90c19fb to
7cff3e6
Compare
… validateToolchain Our PR removed HIP_CONFIG as the 5th argument to validateToolchain, reducing its return tuple from 5 to 4 values. Update test mocks that still returned 5 values to match the new 4-value interface. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…avior tests get_rocm_version() no longer calls hipconfig. Replace the two tests that verified hipconfig invocation with tests for the new behavior: - test_get_rocm_version_uses_rocm_version_env: verifies ROCM_VERSION env var is read and takes priority - test_get_rocm_version_reads_info_version_file: verifies .info/version file is read from ROCM_PATH, covering both simple (7.1.0) and build-suffix (7.1.25424-abc) version string formats Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
hipconfig --platform reads HIP_PLATFORM if set, otherwise auto-detects by checking if clang++ is runnable — always returning 'amd' for AMD-only ROCm builds. Since NVIDIA support has been removed, replace all calls to hipconfig --platform with the literal value 'amd'. - hipblas/rmake.py: remove 7-line hipconfig detection block, replace with single assignment; update --cuda help text - hipblas/install.sh: replace hipconfig call with 'amd'; update help text - hipsolver/install.sh: replace hipconfig call with 'amd' Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
get_rocm_version() no longer calls hipconfig so the hipconfig code path is no longer exercised by the replacement tests. Update the coverage baseline from 99.19% to 94.63% to reflect the new test coverage. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
The previous change unconditionally set HIP_PLATFORM='amd', which overwrote the 'nvidia' value set by the --cuda flag handler above it. Use else branch so --cuda builds correctly set HIP_PLATFORM='nvidia'. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
- Component.py, Common.py: remove rocm_sdk (pip) version detection per Alex-Vasile's suggestion to leave Python ROCm support to PR #11023, which will add it with proper feature-gating infrastructure - Component.py, Common.py: fix nightly/alpha version string parsing; version strings like "10.1.0a20260813" previously caused ValueError when int() was called on "0a20260813"; strip pre-release suffix with re.match(r'\d+', ...) before converting to int - install.sh: correct --cuda help text to accurately reflect that the flag unconditionally sets HIP_PLATFORM=nvidia (previously the text implied HIP_PLATFORM could still be overridden via env var) - Linux_Install_Guide.rst: remove stale "hipconfig --platform" reference; replace with accurate description of the --cuda flag and HIP_PLATFORM defaulting to amd Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
When HIP_PLATFORM=nvidia, rmake.py previously set CUDA_BIN_PATH and relied on hipcc to wrap nvcc. Replace with direct nvcc detection: - Locate nvcc from --cudapath/bin/nvcc or PATH - Pass CMAKE_CUDA_COMPILER and CUDA_TOOLKIT_ROOT_DIR to CMake so find_package(CUDA) and find_package(CUDAToolkit) resolve without any hipcc involvement - Skip the implicit g++ default for the CXX compiler when targeting CUDA (nvcc drives device compilation; letting CMake pick the host compiler is more appropriate than forcing g++) Update install.sh help text and Linux_Install_Guide.rst to reflect that nvcc is now invoked directly and must be on PATH or reachable via --cudapath. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
Remove the HIP_PLATFORM environment variable from the hipBLAS build
entirely and replace it with a first-class CMake boolean option USE_CUDA.
This decouples the CUDA backend selection from hipcc's internal env var
and invokes nvcc directly.
Changes:
- CMakeLists.txt: promote USE_CUDA from deprecated alias to the primary
CMake option; use find_package(CUDAToolkit) instead of find_package(CUDA)
for modern imported targets; remove all ENV{HIP_PLATFORM} reads/writes
- library/src/CMakeLists.txt: replace HIP_PLATFORM checks with USE_CUDA;
link CUDA::cublas (modern CUDAToolkit target) instead of ${CUDA_CUBLAS_LIBRARIES}
- clients/*/CMakeLists.txt, build-options.cmake: replace HIP_PLATFORM
checks with USE_CUDA / NOT USE_CUDA
- rmake.py: remove os.environ['HIP_PLATFORM'] entirely; use local
use_cuda_backend flag; pass -DUSE_CUDA=ON to CMake when --cuda given;
update --cuda help text to remove HIP_PLATFORM reference
- install.sh: replace HIP_PLATFORM env var checks with build_cuda flag;
remove export HIP_PLATFORM lines; update --cuda help text
- Linux_Install_Guide.rst: remove HIP_PLATFORM references; describe
USE_CUDA and nvcc-direct approach
Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…vars in clients
rmake.py: use_cuda_backend was defined as a local in main() but
referenced in config_cmd() which is a separate top-level function —
this caused a NameError on every invocation. Replace with args.use_cuda
directly since args is already module-level.
clients/{benchmarks,gtest,samples}/CMakeLists.txt: after switching from
FindCUDA to FindCUDAToolkit, the client files still referenced legacy
${CUDA_INCLUDE_DIRS} and ${CUDA_LIBRARIES} variables which are empty
with FindCUDAToolkit. Replace with CUDA::cublas which carries its own
include directories transitively, so the explicit target_include_directories
calls are no longer needed.
Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
Two corrections aligned with #11634: library/src/CMakeLists.txt: - Move hip::host to unconditional linkage (PUBLIC on hipblas). The public hipBLAS headers expose HIP types so consumers need hip::host regardless of which backend was built, not just on the AMD path. - Change CUDA::cublas from PRIVATE to PUBLIC and add CUDA::cudart PUBLIC. The public API exposes cuBLAS and CUDA runtime declarations on the CUDA backend, so those usage requirements must propagate to consumers. clients/{benchmarks,gtest,samples}/CMakeLists.txt: - Replace CUDA::cublas with hip::host + CUDA::cudart in client targets. Clients call the hipBLAS API (which wraps cuBLAS) but don't call cuBLAS directly; they need CUDA::cudart for device management and hip::host for HIP allocation/device calls, not the full cuBLAS link. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…not un-deprecation
Address review feedback from Alex-Vasile: the USE_CUDA option is NOT
un-deprecating the old flag. The previous USE_CUDA set ENV{HIP_PLATFORM}
for hipcc/hipconfig. The new USE_CUDA is a proper CMake option that drives
the CUDA backend via FindCUDAToolkit and nvcc directly, with no hipcc or
hipconfig involvement. Add a comment making this distinction explicit.
Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…mpatibility
FindCUDAToolkit (with CUDA:: imported targets) requires CMake 3.17.
The legacy FindCUDA module has been available since CMake 2.8 and avoids
forcing a cmake_minimum_required bump in this PR.
- CMakeLists.txt: find_package(CUDA) instead of find_package(CUDAToolkit)
- library/src: ${CUDA_CUBLAS_LIBRARIES}/${CUDA_LIBRARIES} instead of
CUDA::cublas/CUDA::cudart; explicit CUDA_INCLUDE_DIRS needed since
legacy variables don't propagate includes transitively
- clients/{benchmarks,gtest,samples}: same pattern
Note: FindCUDA is deprecated since CMake 3.10. A follow-on PR can migrate
to FindCUDAToolkit once cmake_minimum_required is raised separately.
Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…g comment
Extends the hipcc/hipconfig deprecation to hipsolver and hipfft:
hipsolver/CMakeLists.txt:
- Replace deprecated USE_CUDA + ENV{HIP_PLATFORM} detection block with a
proper option(USE_CUDA ...) mirroring the hipblas approach
- Remove hipconfig/HIP_PLATFORM detection (find_package(hip CONFIG) always)
- Replace three if(NOT HIP_PLATFORM STREQUAL nvidia) checks with if(NOT USE_CUDA)
hipsolver/install.sh:
- Remove export HIP_PLATFORM="nvidia"/"amd" — now driven by -DUSE_CUDA=ON
passed to CMake; drop the stale $HIP_PLATFORM == "nvidia" OR condition
hipfft/CMakeLists.txt:
- Add option(USE_CUDA ...) and replace ENV{HIP_PLATFORM} read with USE_CUDA
in the BUILD_WITH_COMPILER detection block
- Remove set(HIP_PLATFORM "nvidia"/"amd") — these were set but never consumed
by any downstream hipfft cmake file
hipblas/rmake.py:
- Fix misleading comment: find_package(CUDA) not find_package(CUDAToolkit)
Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
Add a PATH-based fallback in get_rocm_version() (Component.py) and assignGlobalParameters() (Common.py) so that TheRock CI builds succeed when ROCm tools are on PATH but ROCM_PATH is not set and /opt/rocm doesn't exist (e.g. build/core/clr/dist/ layouts). Priority chain: ROCM_VERSION env → ROCM_PATH/HIP_PATH/.info/version → /opt/rocm/.info/version → parent.parent of first found amdclang++, rocm-smi, or amd-smi on PATH. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
The previous PATH-based fallback walked up from the found executable to derive the ROCm root and looked for .info/version, but in TheRock component dist layouts (e.g. build/core/clr/dist/) that file does not exist. Add a second probe that reads include/hip/hip_version.h and extracts HIP_VERSION_MAJOR/MINOR/PATCH, which is present in both standard ROCm installs and TheRock component dists. Priority chain: 1. ROCM_VERSION env var 2. .info/version from ROCM_PATH / HIP_PATH / /opt/rocm 3a. .info/version from parent.parent of amdclang++/rocm-smi on PATH 3b. include/hip/hip_version.h from same candidate root Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…depth The previous fix used parent.parent (2 levels up) from the found executable. But in TheRock, amdclang++ lives at dist/lib/llvm/bin/, making parent.parent = dist/lib/llvm — still too deep to find include/hip/hip_version.h or .info/version at dist/. Switch to walking up to 5 levels from the executable's bin directory, checking .info/version and include/hip/hip_version.h at each ancestor. This covers both dist/bin/amdclang++ (1 step) and dist/lib/llvm/bin/amdclang++ (3 steps). Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
The codecov patch coverage for this PR was 21.43% (target 70.34%), largely because the PATH-based fallback added to get_rocm_version() (Component.py) and assignGlobalParameters() (Common.py) lacked test coverage. These code paths are exercised only in TheRock CI builds where amdclang++ is on PATH but ROCM_PATH is not set and /opt/rocm does not exist — conditions that the existing env-var and .info/version tests do not replicate. Two parametrized test cases are added to each test file to cover the two representative TheRock filesystem layouts: - dist/bin/amdclang++ (1 level up to dist/) - dist/lib/llvm/bin/amdclang++ (3 levels up to dist/) In both cases the test creates a fake executable at the given depth, places include/hip/hip_version.h at the dist root, monkeypatches shutil.which to return the fake executable, and verifies that get_rocm_version() / HipClangVersion resolves to the expected version. The Common.py test additionally patches Path.read_text to reject all .info/version reads, forcing the code to fall through to the hip_version.h branch, since the full assignGlobalParameters() requires an extensive config beyond what version detection needs. Also reverts cmake_minimum_required in hipblas/CMakeLists.txt from 3.17 back to 3.5. The 3.17 bump was a copy-paste error from an earlier draft that used FindCUDAToolkit; the CUDA backend was subsequently switched to legacy FindCUDA (available since CMake 2.8) precisely to avoid raising the minimum version. This addresses Alex-Vasile's review comments (#7, #8) noting the version bump appeared unrelated to the PR's scope. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
cmake_minimum_required was already bumped to 3.17 in develop (#11988). Since FindCUDAToolkit (added in CMake 3.17) is now available, switch the CUDA backend from legacy find_package(CUDA) to find_package(CUDAToolkit) and replace the legacy variables with proper imported targets: ${CUDA_CUBLAS_LIBRARIES} -> CUDA::cublas ${CUDA_LIBRARIES} -> CUDA::cudart ${CUDA_INCLUDE_DIRS} -> handled automatically via CUDA::cudart Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…agent review Addresses findings from the AI assessment at https://github.com/newling/agent-public-reviews/blob/main/rocm-libraries/review_pr7235_v7.md (proposed fixes tracked in #12379). - hipblas/CMakeLists.txt: add find_package(hip) to CUDA branch so hip::host is defined for both backends - hipblas/rmake.py: replace -DCUDA_TOOLKIT_ROOT_DIR with -DCUDAToolkit_ROOT (correct FindCUDAToolkit hint) - shared/tensile/TensileConfig.cmake: use ${HIP_VERSION} instead of ${hip_VERSION} to avoid empty ROCM_VERSION - shared/tensile/test_Common.py: remove unused import tempfile (flake8 F401, fails static-analysis job) - hipfft/CMakeLists.txt: check USE_CUDA before compiler-name detection so -DUSE_CUDA=ON is never silently ignored - test_pchaos_Validators_L226_char.py: remove stale hipcc/hipconfig from POSIX_SUPPORTED model; add as rejected witnesses Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
… lint Three CI failures caused by missing backwards-compatibility for existing CUDA CI jobs that pass HIP_PLATFORM=nvidia without -DUSE_CUDA=ON: - hipfft/CMakeLists.txt: also enter HIP-nvcc path when BUILD_WITH_LIB=CUDA is set, so the existing CI job (hipcc + BUILD_WITH_LIB=CUDA) does not hit the "Detected HIP_COMPILER=clang, but BUILD_WITH_LIB is not ROCM!" fatal error - hipsolver/CMakeLists.txt: promote HIP_PLATFORM=nvidia to USE_CUDA=ON at configure time so all downstream if(USE_CUDA) guards route to the NVIDIA path; prevents find_package(rocblas) from running on a CUDA-only host - shared/tensile/test_Common.py: remove now-unused "from pathlib import Path" import (Path.read_text monkeypatch was replaced by _DEFAULT_ROCM_ROOT redirect); fixes flake8 F401 lint failure Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
The BUILD_WITH_COMPILER="HIP-nvcc" branch wraps all compile and link flags with -Xcompiler= and -Xlinker= prefixes, which are nvcc-specific and rejected by g++ and clang++. The previous condition triggered HIP-nvcc mode based solely on BUILD_WITH_LIB=CUDA, without checking whether nvcc is actually the CXX compiler. This broke the pre-checkin CUDA CI job which passes CMAKE_CXX_COMPILER=g++ alongside BUILD_WITH_LIB=CUDA. Restrict HIP-nvcc mode to builds where CMAKE_CXX_COMPILER is actually nvcc. Compilers such as g++ that target the CUDA backend link against cufft directly and do not need nvcc flag wrapping. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
The previous fix only matched nvcc in the BUILD_WITH_COMPILER=HIP-nvcc condition, breaking the hipcc+CUDA CI path. hipcc wraps nvcc when HIP_PLATFORM=nvidia and legitimately needs -Xcompiler=/-Xlinker= flag wrapping, so include it alongside nvcc in the check. g++ + CUDA → HOST-default (no -Xcompiler wrapping) hipcc + CUDA → HIP-nvcc (-Xcompiler wrapping, hipcc/nvcc handle it) nvcc + CUDA → HIP-nvcc (-Xcompiler wrapping) clang++ + ROCM → HIP-clang (no -Xcompiler wrapping) Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
…PR assessment Changes based on the external review at: https://github.com/newling/agent-public-reviews/blob/main/rocm-libraries/review_pr7235_v8.md - hipfft: normalize USE_CUDA and BUILD_WITH_LIB to a single authoritative value before compiler detection so all downstream consumers see the correct backend - hipfft: consolidate find_package(hip CONFIG) into one unconditional call in CMakeLists.txt, removing the tangled compiler-conditional HIP discovery spread across dependencies.cmake and library/CMakeLists.txt - hipfft: remove the now-redundant set(BUILD_WITH_LIB "CUDA") inside the HIP-NVCC block - hipblas: consolidate duplicate find_package(hip CONFIG) calls from both branches of if(USE_CUDA) into a single unconditional call - hipblas: promote CUDA compiler defines from PRIVATE to PUBLIC so consumers inherit __HIP_PLATFORM_NVIDIA__ when linking against hipBLAS - hipblas: export CUDAToolkit as a package dependency and add a consumer-facing helper that loads hip::host for the NVIDIA backend with a guard against accidentally using an AMD hip::host with a CUDA-built hipBLAS - hipblas: align CUDAToolkit_ROOT with the nvcc found on PATH by resolving symlinks and deriving the root from the actual executable location, preventing mismatched compiler/toolkit installs when the default --cudapath has no nvcc - hipsolver: remove redundant find_package(HIP CONFIG) block in library/CMakeLists.txt that called the same package identically in both if and else branches - hipsolver: forward -DUSE_CUDA=ON to CMake when install.sh --cuda is used directly; previously only rmake.py forwarded this flag, leaving direct install.sh invocations silently building the AMD backend - tensile: find HIP in the package scope before add_subdirectory and capture HIP_VERSION into Tensile_HIP_VERSION so TensileCreateLibraryFiles passes a non-empty ROCM_VERSION to TensileLite; add_subdirectory child scope variables do not propagate back, leaving HIP_VERSION empty at call time - tensile: guard Source/CMakeLists.txt find_package(HIP) with NOT TARGET hip::host to avoid a redundant lookup when the parent scope already found it - tensilelite: replace deprecated hipcc --version subprocess in GlobalParameters.py with get_rocm_version() from the unified version resolver - tensilelite: remove .info/version fallback from Component.py and Common.py; the ROCm release file lacks the HIP build number used for feature gating and silently produces wrong results when patch-level thresholds are checked - tensilelite: update characterization tests to use ROCM_VERSION env var instead of hipcc stubs, and add a test explicitly rejecting .info/version-only installs - tensilelite: restore coverage floors for Assembly.py, HelperKernelCache.py, and Source.py that were unintentionally lowered; those files are unchanged by this PR Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
…st_arch_steppings The gfx1250-strict tests added in develop mock validateToolchain to return 5 values (cxx, cc, bundler, asm, hipConfig). Our PR removed the hipConfig return value, so Run.py now unpacks 4 values. Update both mock lambdas at lines 1691 and 2900 from 5-tuple to 4-tuple to match. Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
… builds When building hipfft with nvcc directly (no hipcc wrapper), CMake must supply the platform defines and HIP headers that hipcc used to inject automatically. Load find_package(hip CONFIG) unconditionally so hip::host is available on both backends, and set __HIP_PLATFORM_NVCC__ and __HIP_PLATFORM_NVIDIA__ for all CUDA builds (not just HOST-DEFAULT). Co-Authored-By: Claude Sonnet 4 (1M context) <noreply@anthropic.com>
PR #10524 (malcolmroberts) modernizes hipFFT's CMake by adding HIP as a first-class CMake language, which is a more comprehensive approach than our manual compiler-detection rewrite. Drop our hipFFT changes to avoid merge conflicts and let the maintainer's PR land cleanly. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…overy The find_package(HIP) call in TensileConfig.cmake ran before add_subdirectory(Source), causing hip-config-amd.cmake to write GPU_TARGETS into the CMake cache via amdgpu-arch auto-detection. This clobbered Tensile's own GPU_TARGETS initialisation, making CI reject targets like gfx950:sramecc+:xnack-. Wrap the HIP discovery in a function that saves and restores the GPU_TARGETS cache entry so Tensile's Source/CMakeLists.txt starts from a clean slate. Also remove the duplicate `import pytest` in test_Common.py that triggered an F811 lint error. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Contributor
TheRock Submodule Bump ActivityNewest first
|
Contributor
|
CMake itself uses The hipconfig tool is also the method by which CMake finds the HIP compiler. The hipconfig lookup of the HIP_CLANG_PATH is the method by which distributions specify which version of clang is the default compiler for the HIP language. If hipconfig is being deprecated, what is replacing it? |
Author
Hi @cgmb good question. I know this PR has already been merged but I should answer this. For now we're really just trying to migrate direct uses of hipconfig in favor of builds using the CMake HIP support. We will continue to ship hipcc/hipconfig for sometime. But the cmake HIP support is able to handle the case where hipconfig is not found. |
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
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.
JIRA ID : LCOMPILER-876
Motivation
hipconfigandhipccare legacy HIP build tools being deprecated in favorof
amdclang++and CMake-native HIP. As part of this migration,HIP_PLATFORMshould no longer be used — it was an environment variable consumed by
hipccto select the AMD or NVIDIA backend, and has no meaning when building directly
with
amdclang++. This PR removeshipconfig/hipccdependencies andreplaces
HIP_PLATFORMbackend selection with an explicitUSE_CUDACMakeoption in the components modified here. Other users in rocm-libraries (MIOpen,
hipDNN, dnn-providers) remain outside this pull request.
Technical Details
hipconfig --versionwith apriority chain:
ROCM_VERSIONenv →share/hip/version→hip_version.h→.info/version, preferring build-version sources soTensileLite patch-field thresholds remain correct.
hipconfig/hipccfrom the validated toolchaintuple; updates characterization tests and restores
Component.pycoverageto 99.54%.
HIP_PLATFORMchecks withUSE_CUDAthroughout CMake files and clients.find_package(hip CONFIG)added to CUDA branch sohip::hostis always defined;
rmake.pycorrected to pass-DCUDAToolkit_ROOT;FindCUDAToolkitimported targets used (requires CMake 3.17 from build(hipblas): require CMake 3.17 (March 2020) for finding util #11988).USE_CUDAcheck moved before compiler-name detection so theexplicit option takes effect with any CXX compiler.
TensileConfig.cmake: passes${HIP_VERSION}(uppercase) to match theupstream
find_package(HIP)variable.Out of scope / future work:
hipconfigusers: MIOpen, hipDNN, dnn-providersFindCUDAtoFindCUDAToolkit(requires bumping
cmake_minimum_requiredto 3.17)-DUSE_CUDA=ONinstead of settingHIP_PLATFORM=nvidiaTest Plan
discovery and toolchain validation.
amdclang++.-DUSE_CUDA=ON.Test Result
amdclang++: pass ✅get_rocm_version,toolchain_component,Validatorsunittests: pass ✅
codecov/patch: 73.81% (target 70.90%) ✅codecov/project/hipBLAS: 90.62% ✅codecov/project/TensileLite-CPP,TensileLite-Unit,hipSOLVER:failing at pre-existing levels, not caused by this PR
-DUSE_CUDA=ON): expected failure — no CUDAtoolkit available in local environment; AMD precheckins pass
Submission Checklist
Risk level
Medium (3/5): changes version discovery and backend selection across five
components; AMD precheckins pass; CUDA backends require a CUDA toolkit to
validate fully.