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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
