[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