[clang] [Clang] Add `-fdefault-generic-addrspace` flag for targeting GPUs (PR #115777)

Joseph Huber via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 11 15:56:23 PST 2024


jhuber6 wrote:

> > This has a lot of unfortable effects that limit using address spaces in C++ as well
> > as making it more difficult to work with.
> 
> Can you give some examples?
> 
> It sounds that what you really want is for address space qualifiers to not be part of a type signature. OpenCL sort of happens to avoid that by sticking `__generic` AS qualifier on all pointers without one, and thus make plain pointers _become_ `__generic` ones, which gets some C++ code happy, but that does look like a quirk of OpenCL. Normally, we a) do not have an explicit generic AS (or it would be indistinguishable from a plain pointer as it is on LLVM level w/ AS(0)), and b) when we specialize a function with an AS-specific pointer type, we generally do want it to be that type.
> 
> Clang and C++ indeed still have issues with AS-qualified pointers. E.g. attempts to define function overloads with `AS(0)` and plain pointers result in an error about conflicting name mangling: https://godbolt.org/z/fW3dP4an5
> 
> Yet C++ does not consider the types equivalent, so you can't pass plain pointer as AS(0)-qualified argument and vice versa: https://godbolt.org/z/K4PEv9e7j
> 
> It's a bug that needs fixing, IMO. We either treat unqualified ans AS(0) pointer types as different, and give them different mangling. Or we should treat AS(0) and plain pointer types the same, diagnose AS0/plain overloads as redefinitions (no need to wait til we run into mangling conflict) and allow using them interchangeably.
> 
> Would straightening this out help with the issue you're trying to solve?

Stuff like this is mostly what I'm talking about https://godbolt.org/z/1K8KGdqe9. I previously wanted to relax the handling of the default address space for all targets, but that made @AlexVlx unhappy in https://github.com/llvm/llvm-project/pull/112248.

https://github.com/llvm/llvm-project/pull/115777


More information about the cfe-commits mailing list