================
@@ -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
