Skip to content

[libclc] Initial support for cross-compiling OpenCL libraries #174022

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jhuber6 merged 1 commit into from
Jan 7, 2026
Merged

[libclc] Initial support for cross-compiling OpenCL libraries #174022

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions libclc/CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,12 @@ set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS

set( LIBCLC_MIN_LLVM 3.9.0 )

set( LIBCLC_TARGETS_TO_BUILD "all"
# A runtimes cross-build should only use the requested target.
set( LIBCLC_DEFAULT_TARGET "all" )
if( LLVM_RUNTIMES_BUILD AND LLVM_DEFAULT_TARGET_TRIPLE MATCHES "^nvptx|^amdgcn" )
set( LIBCLC_DEFAULT_TARGET ${LLVM_DEFAULT_TARGET_TRIPLE} )
endif()
set( LIBCLC_TARGETS_TO_BUILD ${LIBCLC_DEFAULT_TARGET}
Copy link
Contributor

@wenju-he wenju-he Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it better to pass -DLIBCLC_TARGETS_TO_BUILD=${LLVM_DEFAULT_TARGET_TRIPLE} as runtime configuration options so that there is not customization here?

Copy link
Contributor Author

@jhuber6 jhuber6 Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm not completely sold on how to handle this. the fundamental difference here is that we are expecting to build a per-target toolchain. The libclc project completely breaks normal CMake projects by just building a ton of different architectures through custom commands.

We should only be building a single one, that's the expected way these cross-builds work. I think that's something that should be correct by construction. That being said, functionally it's not a major distinction right now because libclc dodges every bit of normal CMake. Normally this would implicitly put --target=amdgcn-amd-amdhsa on all your compiles and that's how you'd get the target code. Since we're doing it manually here it's more to fit in with the expected usage. I.e. the following builds the runtime for your target

-DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES=libclc

I'm not sure if there's a more elegant solution to this. If I had my way we'd rewrite all of this to use a custom language and do it the normal way with the above mechanism. Until then I'm not sure. This was the easiest way I could think of to do it. I have in the past added cache files for required GPU configs, but since this is basically overriding what the runtimes build above is trying to do I'm not so sure.

TL;DR DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES=libclc builds for a single target only and is the expected behavior. libclc doesn't get this because we do everything custom.

Copy link
Contributor

@wenju-he wenju-he Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @jhuber6, the direction looks to me.

CACHE STRING "Semicolon-separated list of libclc targets to build, or 'all'." )

option( ENABLE_RUNTIME_SUBNORMAL "Enable runtime linking of subnormal support." OFF )
Expand Down Expand Up @@ -82,7 +87,10 @@ else()
# In-tree configuration
set( LIBCLC_STANDALONE_BUILD FALSE )

set( LLVM_PACKAGE_VERSION ${LLVM_VERSION} )
if( NOT LLVM_PACKAGE_VERSION )
set( LLVM_PACKAGE_VERSION ${LLVM_VERSION} )
endif()
set( PACKAGE_VERSION ${LLVM_PACKAGE_VERSION} )
Copy link
Contributor

@wenju-he wenju-he Jan 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use LLVM_VERSION_MAJOR? LLVM_PACKAGE_VERSION is not set in in-tree build.

Copy link
Contributor Author

@jhuber6 jhuber6 Jan 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird, LLVM_PACKAGE_VERSION should be set if LLVM_VERSION is set from what I know. We need PACKAGE_VERSION here set so finding the resource directory actually works properly. I suppose I can just set both.

Copy link
Contributor Author

@jhuber6 jhuber6 Jan 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused what in-tree means here. If it's in the context like we're doing here with a runtimes build it should be set.

Copy link
Contributor

@wenju-he wenju-he Jan 5, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused what in-tree means here. If it's in the context like we're doing here with a runtimes build it should be set.

sorry, you're right that LLVM_PACKAGE_VERSION is set in in-tree build when libclc is in LLVM_ENABLE_RUNTIMES.

It is just that our downstream still uses LLVM_ENABLE_PROJECTS="...,libclc" and in this case LLVM_PACKAGE_VERSION is not set. The reasons of not switching to LLVM_ENABLE_RUNTIMES yet are:

  • prepare_builtins has build fail when libclc is in LLVM_ENABLE_RUNTIMES on windows when MSVC generator is used, see Update LLVM google/clspv#1521 (comment) and analysis at Update LLVM google/clspv#1521 (comment). CMAKE_C_COMPILER set at

    llvm-project/llvm/cmake/modules/LLVMExternalProjectUtils.cmake

    Line 228 in 80b62cb

    set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-cl${CMAKE_EXECUTABLE_SUFFIX}
    doesn't work. This could be an blocking issue for switching libclc to add_library since CMAKE_C_COMPILER will be used for compiling .cl files.
  • LLVM_ENABLE_RUNTIMES="libclc" build is much slower than LLVM_ENABLE_PROJECTS="libclc" in debug build when compiling a execution-time support library which depends on libclc. I have a local workaround for this issue and long term solution might be removing the dependency on libclc.

Copy link
Contributor Author

@jhuber6 jhuber6 Jan 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, so just setting both for now is the easiest?

Copy link
Contributor

@wenju-he wenju-he Jan 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, so just setting both for now is the easiest?

yeah. Perhaps this code

llvm-project/flang/CMakeLists.txt

Lines 335 to 337 in 80b62cb

if (NOT PACKAGE_VERSION)
set(PACKAGE_VERSION ${LLVM_VERSION_MAJOR})
endif()
is better.


# Note that we check this later (for both build types) but we can provide a
# more useful error message when built in-tree. We assume that LLVM tools are
Expand Down
Loading