[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/frasercrmck closed https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/frasercrmck edited https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
frasercrmck wrote:
That's probably a good idea, yes. There's a lot of redundancy in having these
large bytecode libraries which are 95% functionally equivalent between
targets/architectures.
I can circle back to this in a follow-up PR to investigate the enabling of the
generic address space support for AMDGPU architectures.
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/arsenm approved this pull request. https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
arsenm wrote:
There isn't a generic target you can just compile for. For amdhsa triples, we
assume the default dummy target-cpu supports flat pointers.
-mlink-builtin-bitcode plus a collection of other hacks let's us get pretty far
in pretending we can have a generic bitcode, but it's fragile system I would
like to get away from.
Long term I think we need better compartmentalization on target feature
dependence. i.e. we should have a base implementation plus the compiler can
select target specific function variants later. In this case the generic
address space is pretty fundamental. I doubt anyone is regularly testing with
gfx6 anywhere, maybe we could just drop them from the support list here. It
also shouldn't be that part to implement software tagged flat pointers, there
would just be a small runtime component required to make it work (which is
driver work which would never really be implemented)
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/frasercrmck updated
https://github.com/llvm/llvm-project/pull/137183
>From fcae18dd0b4af6f7517ba8eda368374fa693a5f9 Mon Sep 17 00:00:00 2001
From: Fraser Cormack
Date: Thu, 24 Apr 2025 11:24:30 +0100
Subject: [PATCH 1/6] [libclc] Support the generic address space
This commit provides definitions of builtins with the generic address
space.
It is assumed that all current libclc targets can support the generic
address space.
One concept to consider is the difference between supporting the generic
address space from the user's perspective, and the requirement for
libclc as a compiler implementation detail to define separate generic
address space builtins. In practice a target (like NVPTX) might
notionally support the generic address space, but it's mapped to the
same LLVM target address space as the private address space. Therefore
libclc may not define both private and generic overloads of the same
builtin. We track these two concepts separately, and make the assumption
that if the generic address space does clash with another, it's with the
private one.
---
libclc/CMakeLists.txt | 25 +++
libclc/clc/include/clc/clcfunc.h | 16
.../clc/math/unary_decl_with_int_ptr.inc | 4 +++
.../include/clc/math/unary_decl_with_ptr.inc | 5
.../clc/math/unary_def_with_int_ptr.inc | 7 ++
.../include/clc/math/unary_def_with_ptr.inc | 7 ++
libclc/clc/lib/generic/math/clc_frexp.cl | 7 ++
libclc/clc/lib/generic/math/clc_modf.inc | 4 +++
libclc/clc/lib/generic/math/clc_sincos.inc| 3 +++
.../opencl/include/clc/opencl/math/remquo.h | 7 ++
.../opencl/include/clc/opencl/shared/vload.h | 16 +++-
.../opencl/include/clc/opencl/shared/vstore.h | 16 +++-
.../opencl/lib/clspv/shared/vstore_half.inc | 6 +
libclc/opencl/lib/generic/math/remquo.inc | 7 ++
libclc/opencl/lib/generic/shared/vload.cl | 11 +++-
.../opencl/lib/generic/shared/vload_half.inc | 6 +
libclc/opencl/lib/generic/shared/vstore.cl| 11 +++-
.../opencl/lib/generic/shared/vstore_half.inc | 7 ++
18 files changed, 161 insertions(+), 4 deletions(-)
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 70b11df3b3142..b8eddb92f3bf5 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
+list( APPEND build_flags "-Xclang"
"-cl-ext=+__opencl_c_generic_address_space" )
+# Note: we assume that if there is no distinct generic address space, it
+# maps to the private address space.
+set ( has_distinct_generic_addrspace TRUE )
+if( ARCH STREQUAL nvptx OR ARCH STREQUAL nvptx64 )
+ set ( has_distinct_generic_addrspace FALSE )
+endif()
+if( has_distinct_generic_addrspace )
+ list( APPEND build_flags -D__CLC_DISTINCT_GENERIC_ADDRSPACE__ )
+endif()
+
set( clc_build_flags ${build_flags} -DCLC_INTERNAL )
add_libclc_builtin_set(
diff --git a/libclc/clc/include/clc/clcfunc.h b/libclc/clc/include/clc/clcfunc.h
index 7c5b31e77a024..e333fe863f990 100644
--- a/libclc/clc/include/clc/clcfunc.h
+++ b/libclc/clc/include/clc/clcfunc.h
@@ -23,4 +23,20 @@
#define _CLC_DEF __attribute__((always_inline))
#endif
+#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 ||
\
+(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 &&
\
+ defined(__opencl_c_generic_address_space))
+#define _CLC_GENERIC_AS_SUPPORTED 1
+// Note that we hard-code the assumption that a non-distinct address space
means
+// that the target maps the generic address space to the private address space.
+#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__
+#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1
+#else
+#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0
+#endif
+#else
+#define _CLC_GENERIC_AS_SUPPORT
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
frasercrmck wrote:
With #137940 we can remove this CMake logic, thanks all!
One result of #137636 is that (I believe) because of the default AMDGPU devices
we compile libclc for, the generic address space isn't being enabled by default
for any AMDGPU target in this PR. Should we perhaps be building libclc for a
newer AMDGCN device? It should be at least GFX700 for generic address space
support.
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -23,4 +23,20 @@ #define _CLC_DEF __attribute__((always_inline)) #endif +#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 || \ +(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 && \ + defined(__opencl_c_generic_address_space)) +#define _CLC_GENERIC_AS_SUPPORTED 1 +// Note that we hard-code the assumption that a non-distinct address space means +// that the target maps the generic address space to the private address space. +#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__ +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1 +#else +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0 +#endif +#else frasercrmck wrote: I've updated the PR. It's mostly to keep it up to date with the changes that have landed in clang, so we can remove the CMake logic. As part of this, CMake now passes in the private and generic address space values based on the target via macro defs. The clcfunc.h header now checks for equality of the two values before deciding whether the 'distinct' generic address space is supported. I haven't changed the names of the macros out of simplicity, but also in part because I'd prefer if the check was done once centrally so users can rely on a simple `#if/#else` when it comes to defining/declaring builtins. https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff HEAD~1 HEAD --extensions inc,h,cl -- libclc/clc/include/clc/clcfunc.h libclc/clc/include/clc/math/remquo_decl.inc libclc/clc/include/clc/math/unary_decl_with_int_ptr.inc libclc/clc/include/clc/math/unary_decl_with_ptr.inc libclc/clc/include/clc/math/unary_def_with_int_ptr.inc libclc/clc/include/clc/math/unary_def_with_ptr.inc libclc/clc/lib/generic/math/clc_fract.inc libclc/clc/lib/generic/math/clc_frexp.cl libclc/clc/lib/generic/math/clc_modf.inc libclc/clc/lib/generic/math/clc_remquo.cl libclc/clc/lib/generic/math/clc_sincos.inc libclc/opencl/include/clc/opencl/math/remquo.h libclc/opencl/include/clc/opencl/shared/vload.h libclc/opencl/include/clc/opencl/shared/vstore.h libclc/opencl/lib/clspv/shared/vstore_half.inc libclc/opencl/lib/generic/math/remquo.inc libclc/opencl/lib/generic/shared/vload.cl libclc/opencl/lib/generic/shared/vload_half.inc libclc/opencl/lib/generic/shared/vstore.cl libclc/opencl/lib/generic/shared/vstore_half.inc `` View the diff from clang-format here. ``diff diff --git a/libclc/clc/lib/generic/math/clc_frexp.cl b/libclc/clc/lib/generic/math/clc_frexp.cl index 041caec5a..7ff292ebb 100644 --- a/libclc/clc/lib/generic/math/clc_frexp.cl +++ b/libclc/clc/lib/generic/math/clc_frexp.cl @@ -6,8 +6,8 @@ // //===--===// -#include #include +#include #include #include #include `` https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/frasercrmck updated
https://github.com/llvm/llvm-project/pull/137183
>From fcae18dd0b4af6f7517ba8eda368374fa693a5f9 Mon Sep 17 00:00:00 2001
From: Fraser Cormack
Date: Thu, 24 Apr 2025 11:24:30 +0100
Subject: [PATCH 1/5] [libclc] Support the generic address space
This commit provides definitions of builtins with the generic address
space.
It is assumed that all current libclc targets can support the generic
address space.
One concept to consider is the difference between supporting the generic
address space from the user's perspective, and the requirement for
libclc as a compiler implementation detail to define separate generic
address space builtins. In practice a target (like NVPTX) might
notionally support the generic address space, but it's mapped to the
same LLVM target address space as the private address space. Therefore
libclc may not define both private and generic overloads of the same
builtin. We track these two concepts separately, and make the assumption
that if the generic address space does clash with another, it's with the
private one.
---
libclc/CMakeLists.txt | 25 +++
libclc/clc/include/clc/clcfunc.h | 16
.../clc/math/unary_decl_with_int_ptr.inc | 4 +++
.../include/clc/math/unary_decl_with_ptr.inc | 5
.../clc/math/unary_def_with_int_ptr.inc | 7 ++
.../include/clc/math/unary_def_with_ptr.inc | 7 ++
libclc/clc/lib/generic/math/clc_frexp.cl | 7 ++
libclc/clc/lib/generic/math/clc_modf.inc | 4 +++
libclc/clc/lib/generic/math/clc_sincos.inc| 3 +++
.../opencl/include/clc/opencl/math/remquo.h | 7 ++
.../opencl/include/clc/opencl/shared/vload.h | 16 +++-
.../opencl/include/clc/opencl/shared/vstore.h | 16 +++-
.../opencl/lib/clspv/shared/vstore_half.inc | 6 +
libclc/opencl/lib/generic/math/remquo.inc | 7 ++
libclc/opencl/lib/generic/shared/vload.cl | 11 +++-
.../opencl/lib/generic/shared/vload_half.inc | 6 +
libclc/opencl/lib/generic/shared/vstore.cl| 11 +++-
.../opencl/lib/generic/shared/vstore_half.inc | 7 ++
18 files changed, 161 insertions(+), 4 deletions(-)
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 70b11df3b3142..b8eddb92f3bf5 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
+list( APPEND build_flags "-Xclang"
"-cl-ext=+__opencl_c_generic_address_space" )
+# Note: we assume that if there is no distinct generic address space, it
+# maps to the private address space.
+set ( has_distinct_generic_addrspace TRUE )
+if( ARCH STREQUAL nvptx OR ARCH STREQUAL nvptx64 )
+ set ( has_distinct_generic_addrspace FALSE )
+endif()
+if( has_distinct_generic_addrspace )
+ list( APPEND build_flags -D__CLC_DISTINCT_GENERIC_ADDRSPACE__ )
+endif()
+
set( clc_build_flags ${build_flags} -DCLC_INTERNAL )
add_libclc_builtin_set(
diff --git a/libclc/clc/include/clc/clcfunc.h b/libclc/clc/include/clc/clcfunc.h
index 7c5b31e77a024..e333fe863f990 100644
--- a/libclc/clc/include/clc/clcfunc.h
+++ b/libclc/clc/include/clc/clcfunc.h
@@ -23,4 +23,20 @@
#define _CLC_DEF __attribute__((always_inline))
#endif
+#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 ||
\
+(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 &&
\
+ defined(__opencl_c_generic_address_space))
+#define _CLC_GENERIC_AS_SUPPORTED 1
+// Note that we hard-code the assumption that a non-distinct address space
means
+// that the target maps the generic address space to the private address space.
+#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__
+#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1
+#else
+#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0
+#endif
+#else
+#define _CLC_GENERIC_AS_SUPPORT
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -23,4 +23,20 @@ #define _CLC_DEF __attribute__((always_inline)) #endif +#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 || \ +(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 && \ + defined(__opencl_c_generic_address_space)) +#define _CLC_GENERIC_AS_SUPPORTED 1 +// Note that we hard-code the assumption that a non-distinct address space means +// that the target maps the generic address space to the private address space. +#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__ +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1 +#else +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0 +#endif +#else arsenm wrote: This is ultimately a clang bug. The two functions are different symbols. addressSpaceMapManglingFor shouldn't be reporting true in the colliding cases https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -23,4 +23,20 @@ #define _CLC_DEF __attribute__((always_inline)) #endif +#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 || \ +(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 && \ + defined(__opencl_c_generic_address_space)) +#define _CLC_GENERIC_AS_SUPPORTED 1 +// Note that we hard-code the assumption that a non-distinct address space means +// that the target maps the generic address space to the private address space. +#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__ +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1 +#else +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0 +#endif +#else frasercrmck wrote: Yes, something like that. Thanks for clarifying, I was half wondering if you meant adding some new macro definition to clang itself. I am a bit hesitant to encode actual address space values in libclc as it's ultimately up to clang (and may differ depending on the subtarget/CPU), but either way unless clang gives us more information we have to encode _some_ kind of assumption in libclc. Having some kind of introspection available about the address space mappings would be nice but overkill. It looks like every target uses `private = 0` except for AMDGPU which has `private = 5`. For `generic` we have mostly `0` too, except for DirectX and SPIR (which I think influences SPIRV?) which use `4`. It's doable using some preprocessorr logic, or some defs passed in from CMake as build options, but I'd worry a bit about it getting out of sync with the actual compiler. I think the macro could definitely be better worded to include the assumption of "private". Something along the lines of `GENERIC_IS_(NOT_)PRIVATE` or whatever. Ultimately this only applies to NVPTX so there's also the possibility of using the NVPTX target rather than trying to come up with something general. At least if anything goes wrong it would fail at build time. https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -23,4 +23,20 @@ #define _CLC_DEF __attribute__((always_inline)) #endif +#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 || \ +(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 && \ + defined(__opencl_c_generic_address_space)) +#define _CLC_GENERIC_AS_SUPPORTED 1 +// Note that we hard-code the assumption that a non-distinct address space means +// that the target maps the generic address space to the private address space. +#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__ +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1 +#else +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0 +#endif +#else arsenm wrote: Even if not this, the current name is misleading. It's not about generic being supported, if anything it's more like private isn't real https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/frasercrmck updated
https://github.com/llvm/llvm-project/pull/137183
>From 253bbc8cf673dd1d0ca606058dbd26e15cee651a Mon Sep 17 00:00:00 2001
From: Fraser Cormack
Date: Thu, 24 Apr 2025 11:24:30 +0100
Subject: [PATCH 1/2] [libclc] Support the generic address space
This commit provides definitions of builtins with the generic address
space.
It is assumed that all current libclc targets can support the generic
address space.
One concept to consider is the difference between supporting the generic
address space from the user's perspective, and the requirement for
libclc as a compiler implementation detail to define separate generic
address space builtins. In practice a target (like NVPTX) might
notionally support the generic address space, but it's mapped to the
same LLVM target address space as the private address space. Therefore
libclc may not define both private and generic overloads of the same
builtin. We track these two concepts separately, and make the assumption
that if the generic address space does clash with another, it's with the
private one.
---
libclc/CMakeLists.txt | 25 +++
libclc/clc/include/clc/clcfunc.h | 16
.../clc/math/unary_decl_with_int_ptr.inc | 4 +++
.../include/clc/math/unary_decl_with_ptr.inc | 5
.../clc/math/unary_def_with_int_ptr.inc | 7 ++
.../include/clc/math/unary_def_with_ptr.inc | 7 ++
libclc/clc/lib/generic/math/clc_frexp.cl | 7 ++
libclc/clc/lib/generic/math/clc_modf.inc | 4 +++
libclc/clspv/lib/shared/vstore_half.inc | 6 +
libclc/generic/include/clc/math/frexp.inc | 4 +++
libclc/generic/include/clc/math/remquo.h | 7 ++
libclc/generic/include/clc/math/sincos.inc| 4 +++
libclc/generic/include/clc/shared/vload.h | 16 +++-
libclc/generic/include/clc/shared/vstore.h| 16 +++-
libclc/generic/lib/math/remquo.cl | 7 ++
libclc/generic/lib/math/sincos.inc| 3 +++
libclc/generic/lib/shared/vload.cl| 11 +++-
libclc/generic/lib/shared/vload_half.inc | 6 +
libclc/generic/lib/shared/vstore.cl | 11 +++-
libclc/generic/lib/shared/vstore_half.inc | 7 ++
20 files changed, 169 insertions(+), 4 deletions(-)
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 50ddfc3930cd3..d1f09114d6e54 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
+list( APPEND build_flags "-Xclang"
"-cl-ext=+__opencl_c_generic_address_space" )
+# Note: we assume that if there is no distinct generic address space, it
+# maps to the private address space.
+set ( has_distinct_generic_addrspace TRUE )
+if( ARCH STREQUAL nvptx OR ARCH STREQUAL nvptx64 )
+ set ( has_distinct_generic_addrspace FALSE )
+endif()
+if( has_distinct_generic_addrspace )
+ list( APPEND build_flags -D__CLC_DISTINCT_GENERIC_ADDRSPACE__ )
+endif()
+
set( clc_build_flags ${build_flags} -DCLC_INTERNAL )
add_libclc_builtin_set(
diff --git a/libclc/clc/include/clc/clcfunc.h b/libclc/clc/include/clc/clcfunc.h
index 7c5b31e77a024..e333fe863f990 100644
--- a/libclc/clc/include/clc/clcfunc.h
+++ b/libclc/clc/include/clc/clcfunc.h
@@ -23,4 +23,20 @@
#define _CLC_DEF __attribute__((always_inline))
#endif
+#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 ||
\
+(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 &&
\
+ defined(__opencl_c_generic_address_space))
+#define _CLC_GENERIC_AS_SUPPORTED 1
+// Note that we hard-code the assumption that a non-distinct address space
means
+// that the target maps the generic address space to the private address space.
+#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__
+#define _CLC_DISTINCT_GENERIC_AS_
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -23,4 +23,20 @@ #define _CLC_DEF __attribute__((always_inline)) #endif +#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 || \ +(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 && \ + defined(__opencl_c_generic_address_space)) +#define _CLC_GENERIC_AS_SUPPORTED 1 +// Note that we hard-code the assumption that a non-distinct address space means +// that the target maps the generic address space to the private address space. +#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__ +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1 +#else +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0 +#endif +#else arsenm wrote: I mean something like ``` #define __libclc_generic_addrspace_val 0 #define __libclc_private_addrspace_val 5 #if __libclc_private_addrspace_val == __libclc_generic_addrspace_val // ... #endif ``` https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/frasercrmck updated
https://github.com/llvm/llvm-project/pull/137183
>From 3519e1c571375802d77937e765d551607ed5bdde Mon Sep 17 00:00:00 2001
From: Fraser Cormack
Date: Thu, 24 Apr 2025 11:24:30 +0100
Subject: [PATCH 1/2] [libclc] Support the generic address space
This commit provides definitions of builtins with the generic address
space.
It is assumed that all current libclc targets can support the generic
address space.
One concept to consider is the difference between supporting the generic
address space from the user's perspective, and the requirement for
libclc as a compiler implementation detail to define separate generic
address space builtins. In practice a target (like NVPTX) might
notionally support the generic address space, but it's mapped to the
same LLVM target address space as the private address space. Therefore
libclc may not define both private and generic overloads of the same
builtin. We track these two concepts separately, and make the assumption
that if the generic address space does clash with another, it's with the
private one.
---
libclc/CMakeLists.txt | 25 +++
libclc/clc/include/clc/clcfunc.h | 16
.../clc/math/unary_decl_with_int_ptr.inc | 4 +++
.../include/clc/math/unary_decl_with_ptr.inc | 5
.../clc/math/unary_def_with_int_ptr.inc | 7 ++
.../include/clc/math/unary_def_with_ptr.inc | 7 ++
libclc/clc/lib/generic/math/clc_frexp.cl | 7 ++
libclc/clc/lib/generic/math/clc_modf.inc | 4 +++
libclc/clspv/lib/shared/vstore_half.inc | 6 +
libclc/generic/include/clc/math/fract.inc | 13 +++---
libclc/generic/include/clc/math/frexp.inc | 4 +++
libclc/generic/include/clc/math/remquo.h | 7 ++
libclc/generic/include/clc/math/sincos.inc| 4 +++
libclc/generic/include/clc/shared/vload.h | 16 +++-
libclc/generic/include/clc/shared/vstore.h| 16 +++-
libclc/generic/lib/math/fract.inc | 4 +++
libclc/generic/lib/math/remquo.cl | 7 ++
libclc/generic/lib/math/sincos.inc| 3 +++
libclc/generic/lib/shared/vload.cl| 11 +++-
libclc/generic/lib/shared/vload_half.inc | 6 +
libclc/generic/lib/shared/vstore.cl | 11 +++-
libclc/generic/lib/shared/vstore_half.inc | 7 ++
22 files changed, 183 insertions(+), 7 deletions(-)
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 50ddfc3930cd3..d1f09114d6e54 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
+list( APPEND build_flags "-Xclang"
"-cl-ext=+__opencl_c_generic_address_space" )
+# Note: we assume that if there is no distinct generic address space, it
+# maps to the private address space.
+set ( has_distinct_generic_addrspace TRUE )
+if( ARCH STREQUAL nvptx OR ARCH STREQUAL nvptx64 )
+ set ( has_distinct_generic_addrspace FALSE )
+endif()
+if( has_distinct_generic_addrspace )
+ list( APPEND build_flags -D__CLC_DISTINCT_GENERIC_ADDRSPACE__ )
+endif()
+
set( clc_build_flags ${build_flags} -DCLC_INTERNAL )
add_libclc_builtin_set(
diff --git a/libclc/clc/include/clc/clcfunc.h b/libclc/clc/include/clc/clcfunc.h
index 7c5b31e77a024..e333fe863f990 100644
--- a/libclc/clc/include/clc/clcfunc.h
+++ b/libclc/clc/include/clc/clcfunc.h
@@ -23,4 +23,20 @@
#define _CLC_DEF __attribute__((always_inline))
#endif
+#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 ||
\
+(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 &&
\
+ defined(__opencl_c_generic_address_space))
+#define _CLC_GENERIC_AS_SUPPORTED 1
+// Note that we hard-code the assumption that a non-distinct address space
means
+// that the target maps the generic ad
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -12,3 +12,7 @@ _CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE __CLC_FUNCTION(__CLC_GENTYPE x, local __CLC_INTN *iptr); _CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE __CLC_FUNCTION(__CLC_GENTYPE x, private __CLC_INTN *iptr); +#if _CLC_DISTINCT_GENERIC_AS_SUPPORTED +_CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE __CLC_FUNCTION(__CLC_GENTYPE x, + generic __CLC_INTN *iptr); frasercrmck wrote: True, good spot. We do still need to guard them with the generic address space being available, so I'll make that switch. I think I'll use the centrally defined macro `_CLC_GENERIC_AS_SUPPORTED` as opposed to repeating the more unwieldy `#if version == 2.0 || (version >= 3.0 && defined __opencl_c_generic_address_space)`. https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
frasercrmck wrote:
See the first PR for AMDGPU support:
https://github.com/llvm/llvm-project/pull/137636.
I'll do a separate one for NVPTX. It looks like SPIRV (and X86) enable all by
default. That should cover all libclc targets.
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -23,4 +23,20 @@ #define _CLC_DEF __attribute__((always_inline)) #endif +#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 || \ +(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 && \ + defined(__opencl_c_generic_address_space)) +#define _CLC_GENERIC_AS_SUPPORTED 1 +// Note that we hard-code the assumption that a non-distinct address space means +// that the target maps the generic address space to the private address space. +#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__ +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1 +#else +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0 +#endif +#else frasercrmck wrote: > These macro names are too general for the implementation. I don't think this > works for anything other than the 0-is-private-and-generic case. Yes the assumption is very much currently that it's either fully distinct or 0-is-both. I didn't know how much effort to put into making it fully flexible given our list of targets is fairly static. I'd be open to making it more flexible. I don't think there's anything technically stopping a target having two or more of `constant`, `local` and `global` mangle to the same target address space, for example. Do we want something in libclc that can take care of all possibilities, or just the `generic` space with another? > What if you defined a qualifier macro with the value, and check if they are > equal Could you expand on this, sorry? https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
arsenm wrote:
yes (although for amdgpu it needs to skip the ancient targets without flat
addressing)
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
wenju-he wrote:
we should enable __opencl_c_generic_address_space for amdgpu and nvptx in
setSupportedOpenCLOpts API rather than in this CMakeLists file, right?
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -12,3 +12,7 @@ _CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE __CLC_FUNCTION(__CLC_GENTYPE x, local __CLC_INTN *iptr); _CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE __CLC_FUNCTION(__CLC_GENTYPE x, private __CLC_INTN *iptr); +#if _CLC_DISTINCT_GENERIC_AS_SUPPORTED +_CLC_OVERLOAD _CLC_DECL __CLC_GENTYPE __CLC_FUNCTION(__CLC_GENTYPE x, + generic __CLC_INTN *iptr); arsenm wrote: Multiple declarations should be ok https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -23,4 +23,20 @@ #define _CLC_DEF __attribute__((always_inline)) #endif +#if __OPENCL_C_VERSION__ == CL_VERSION_2_0 || \ +(__OPENCL_C_VERSION__ >= CL_VERSION_3_0 && \ + defined(__opencl_c_generic_address_space)) +#define _CLC_GENERIC_AS_SUPPORTED 1 +// Note that we hard-code the assumption that a non-distinct address space means +// that the target maps the generic address space to the private address space. +#ifdef __CLC_DISTINCT_GENERIC_ADDRSPACE__ +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 1 +#else +#define _CLC_DISTINCT_GENERIC_AS_SUPPORTED 0 +#endif +#else arsenm wrote: These macro names are too general for the implementation. I don't think this works for anything other than the 0-is-private-and-generic case. What if you defined a qualifier macro with the value, and check if they are equal https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
arsenm wrote:
Yes, the extension should be reported as available or not by the target macros
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
arsenm wrote: > It is actually [supported in the Itanium > mangler](https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/ItaniumMangle.cpp#L2786): I don't remember this part of the hack. There was a recent fix to always use the correct mapping values for AMDGPU when generic address space is enabled (which should be the only mapping, still need to do something about the setAddressSpaceMap hack). https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
frasercrmck wrote:
> There is a clang bug if there is different mangling. The itanium mangling
> should be coming from the source type / original address space, not whatever
> IR address space value that happens to map to
Yeah, that would be nice but this is what's happening, I'm afraid.
It is actually [supported in the Itanium
mangler](https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/ItaniumMangle.cpp#L2786):
``` cpp
if (Context.getASTContext().addressSpaceMapManglingFor(AS)) {
// ::= "AS"
unsigned TargetAS = Context.getASTContext().getTargetAddressSpace(AS);
if (TargetAS != 0 ||
Context.getASTContext().getTargetAddressSpace(LangAS::Default) != 0)
ASString = "AS" + llvm::utostr(TargetAS);
} else {
switch (AS) {
default: llvm_unreachable("Not a language specific address space");
// ::= "CL" [ "global" | "local" | "constant" |
//"private"| "generic" | "device" |
//"host" ]
case LangAS::opencl_global:
ASString = "CLglobal";
break;
```
It's just that targets we care about in libclc unconditionally enable that
address space map mangling for all address spaces, such as
[AMDGPU](https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/AMDGPU.cpp#L246)
and
[NVPTX](https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/NVPTX.cpp#L58).
I'm not sure I would want to change this behaviour at this point. At least not
for the purposes of enabling generic address space support in libclc. There
will be a bunch of downstream toolchains that rely on the current mangling
scheme.
https://github.com/llvm/llvm-project/pull/137183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/arsenm edited https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/arsenm commented: Even as a compiler implementation detail, libclc should not need to consider the address space mapping. There is a clang bug if there is different mangling. The itanium mangling should be coming from the source type / original address space, not whatever IR address space value that happens to map to https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Support the generic address space (PR #137183)
https://github.com/frasercrmck created
https://github.com/llvm/llvm-project/pull/137183
This commit provides definitions of builtins with the generic address space.
It is assumed that all current libclc targets can support the generic address
space.
One concept to consider is the difference between supporting the generic
address space from the user's perspective and the requirement for libclc as a
compiler implementation detail to define separate generic address space
builtins. In practice a target (like NVPTX) might notionally support the
generic address space, but it's mapped to the same LLVM target address space as
another address space (often the private one).
In such cases libclc must be careful not to define both private and generic
overloads of the same builtin. We track these two concepts separately, and make
the assumption that if the generic address space does clash with another, it's
with the private one. We track the concepts separately because there are some
builtins such as atomics that are defined for the generic address space but not
the private address space.
>From 3519e1c571375802d77937e765d551607ed5bdde Mon Sep 17 00:00:00 2001
From: Fraser Cormack
Date: Thu, 24 Apr 2025 11:24:30 +0100
Subject: [PATCH] [libclc] Support the generic address space
This commit provides definitions of builtins with the generic address
space.
It is assumed that all current libclc targets can support the generic
address space.
One concept to consider is the difference between supporting the generic
address space from the user's perspective, and the requirement for
libclc as a compiler implementation detail to define separate generic
address space builtins. In practice a target (like NVPTX) might
notionally support the generic address space, but it's mapped to the
same LLVM target address space as the private address space. Therefore
libclc may not define both private and generic overloads of the same
builtin. We track these two concepts separately, and make the assumption
that if the generic address space does clash with another, it's with the
private one.
---
libclc/CMakeLists.txt | 25 +++
libclc/clc/include/clc/clcfunc.h | 16
.../clc/math/unary_decl_with_int_ptr.inc | 4 +++
.../include/clc/math/unary_decl_with_ptr.inc | 5
.../clc/math/unary_def_with_int_ptr.inc | 7 ++
.../include/clc/math/unary_def_with_ptr.inc | 7 ++
libclc/clc/lib/generic/math/clc_frexp.cl | 7 ++
libclc/clc/lib/generic/math/clc_modf.inc | 4 +++
libclc/clspv/lib/shared/vstore_half.inc | 6 +
libclc/generic/include/clc/math/fract.inc | 13 +++---
libclc/generic/include/clc/math/frexp.inc | 4 +++
libclc/generic/include/clc/math/remquo.h | 7 ++
libclc/generic/include/clc/math/sincos.inc| 4 +++
libclc/generic/include/clc/shared/vload.h | 16 +++-
libclc/generic/include/clc/shared/vstore.h| 16 +++-
libclc/generic/lib/math/fract.inc | 4 +++
libclc/generic/lib/math/remquo.cl | 7 ++
libclc/generic/lib/math/sincos.inc| 3 +++
libclc/generic/lib/shared/vload.cl| 11 +++-
libclc/generic/lib/shared/vload_half.inc | 6 +
libclc/generic/lib/shared/vstore.cl | 11 +++-
libclc/generic/lib/shared/vstore_half.inc | 7 ++
22 files changed, 183 insertions(+), 7 deletions(-)
diff --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 50ddfc3930cd3..d1f09114d6e54 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -420,12 +420,37 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
-D${CLC_TARGET_DEFINE}
# All libclc builtin libraries see CLC headers
-I${CMAKE_CURRENT_SOURCE_DIR}/clc/include
+ # Error on undefined macros
+ -Werror=undef
)
if( NOT "${cpu}" STREQUAL "" )
list( APPEND build_flags -mcpu=${cpu} )
endif()
+# Generic address space support.
+# Note: when declaring builtins, we must consider that even if a target
+# formally/nominally supports the generic address space, in practice that
+# target may map it to the same target address space as another address
+# space (often the private one). In such cases we must be careful not to
+# multiply-define a builtin in a single target address space, as it would
+# result in a mangling clash.
+# For this reason we must consider the target support of the generic
+# address space separately from the *implementation* decision about whether
+# to declare certain builtins in that address space.
+# FIXME: Shouldn't clang automatically enable this extension based on the
+# target?
+list( APPEND build_flags "-Xclang"
"-cl-ext=+__opencl_c_generic_address_space" )
+# Note: we assume that if there is no distinct generic address space, it
+# maps to the private address space.
+set ( has_distinct_
[libclc] [libclc] Support the generic address space (PR #137183)
frasercrmck wrote: CC @wenju-he https://github.com/llvm/llvm-project/pull/137183 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
