[libclc] [libclc] Support the generic address space (PR #137183)
Fraser Cormack via cfe-commits
cfe-commits at lists.llvm.org
Thu Apr 24 09:14:12 PDT 2025
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)) {
// <target-addrspace> ::= "AS" <address-space-number>
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");
// <OpenCL-addrspace> ::= "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
More information about the cfe-commits
mailing list