================
@@ -915,6 +916,65 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
Builder.defineMacro("__OPENCL_MEMORY_SCOPE_ALL_SVM_DEVICES", "3");
Builder.defineMacro("__OPENCL_MEMORY_SCOPE_SUB_GROUP", "4");
+ auto DefineAddressSpaceMacro = [&](StringRef Name, AddressSpaceQuery::ID AS)
{
+ Builder.defineMacro(Name, Twine(static_cast<unsigned>(AS)));
+ };
+
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_DEFAULT",
+ AddressSpaceQuery::Default);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_OPENCL_GLOBAL",
+ AddressSpaceQuery::OpenCLGlobal);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_OPENCL_LOCAL",
+ AddressSpaceQuery::OpenCLLocal);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_OPENCL_CONSTANT",
+ AddressSpaceQuery::OpenCLConstant);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_OPENCL_PRIVATE",
+ AddressSpaceQuery::OpenCLPrivate);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_OPENCL_GENERIC",
+ AddressSpaceQuery::OpenCLGeneric);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_CUDA_DEVICE",
+ AddressSpaceQuery::CUDADevice);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_CUDA_CONSTANT",
+ AddressSpaceQuery::CUDAConstant);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_CUDA_SHARED",
+ AddressSpaceQuery::CUDAShared);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_SYCL_GLOBAL",
+ AddressSpaceQuery::SYCLGlobal);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_SYCL_LOCAL",
+ AddressSpaceQuery::SYCLLocal);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_SYCL_PRIVATE",
+ AddressSpaceQuery::SYCLPrivate);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_PTR32_SPTR",
+ AddressSpaceQuery::Ptr32Sptr);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_PTR32_UPTR",
+ AddressSpaceQuery::Ptr32Uptr);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_PTR64",
+ AddressSpaceQuery::Ptr64);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HLSL_GROUPSHARED",
+ AddressSpaceQuery::HLSLGroupShared);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HLSL_CONSTANT",
+ AddressSpaceQuery::HLSLConstant);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HLSL_PRIVATE",
+ AddressSpaceQuery::HLSLPrivate);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HLSL_DEVICE",
+ AddressSpaceQuery::HLSLDevice);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HLSL_INPUT",
+ AddressSpaceQuery::HLSLInput);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HLSL_OUTPUT",
+ AddressSpaceQuery::HLSLOutput);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HLSL_PUSH_CONSTANT",
+ AddressSpaceQuery::HLSLPushConstant);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_WASM_FUNCREF",
+ AddressSpaceQuery::WasmFuncRef);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HIP_DEVICE",
+ AddressSpaceQuery::HIPDevice);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HIP_CONSTANT",
+ AddressSpaceQuery::HIPConstant);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_HIP_SHARED",
+ AddressSpaceQuery::HIPShared);
+ DefineAddressSpaceMacro("__CLANG_ADDRESS_SPACE_TARGET_OFFSET",
+ AddressSpaceQuery::TargetOffset);
----------------
yxsamliu wrote:
@tahonermann Re: address-space value names
Thanks, I agree that exposing Clang's internal `LangAS` values directly is not
a good public interface.
One motivation for `__addrspaceof` is to let libraries specialize code based on
memory region and write faster code. Because of that, I don't think the
returned value space should be limited only to address spaces that are common
across all languages today.
Some address spaces may start as language-specific because only one language
exposes that memory feature today. Later, another language or backend may adopt
the same concept. If we collapse such values too early, users lose the ability
to distinguish a real semantic difference. So I think the public values should
be a documented superset of semantic address-space kinds: common regions can
share values, but distinct regions should still have stable named values.
Languages that do not support a given region would simply never produce that
value.
For the named values, I agree that predefined identifiers would be cleaner than
macros in principle. The difficulty is that they are a larger language/frontend
design issue. We would need to define their type, scope, redeclaration rules, C
vs C++ behavior, module/PCH serialization, and whether they are visible in
every translation unit without including a header. Enum constants have similar
questions, and they also would not work in `#if`.
For now I kept them as predefined macros because Clang already uses that model
for builtin-related numeric constants such as `__ATOMIC_*`, `__MEMORY_SCOPE_*`,
`__OPENCL_MEMORY_SCOPE_*`, and `__FPCLASS_*`. Since they are macros, I changed
the spelling to uppercase `__ADDRSPACE_*`.
https://github.com/llvm/llvm-project/pull/210242
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
