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

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> I think I generally agree with @AlexVlx argument. While the patch may solve you immediate issue, I think it's not going to give you a usable compilation model for AS-qualified pointers.
> 
> If you are defining your own C++ extension along the lines of CUDA/HIP/OpenCL, you would have some wiggle room on how you want things to behave, but if you want it to be a regular C++ compilation, you've got to play by C++ rules. The diagnostics in your example looks quite sensible to me -- you're asking compiler to do with things of different types, but you do not provide implementation for it. and because C++ has no idea about what can and can't be done with non-default AS, it's all on you to do it.
> 
> I don't think you can have this cake (explicit AS-qualified pointers) and eat it (make them all usable out of the box in a consistent manner, magically compatible with everything C++). Sticking `__generic` on plain pointer types will likely lead to issues.
> 
> For example, it looks like the pointer promotion will be ABI-breaking. How will you mangle function names with pointer arguments? Normally AS is encoded in the mangled name. And both the caller and callee must be in sync in order to call the right function -> therefore everything must be compiled with the same setting of this flag, including libc, etc.

I agree in general that C/C++ has no semantic meaning ascribed to address spaces, so we cannot rely on intelligent semantic checking since C++ is strongly typed. Realizing that this literally changes all the address spaces makes it a bit difficult to argue that it's just C++, however it's pretty much impossible to use classes as-is since we cannot convert `this` to the object's address space.

I think this approach is fine as an opt-in to have really lenient rules, since that's what AMDGPU and CUDA support already... But doing it with `opencl_generic` does not seem the way as you mentioned, since now every function gets a different mangling, and templates all work different.

This was the 'easy' solution, alternatives would be to allow this for target specific address spaces (i.e. AMDGPU supports any addrspace to default). Another solution would be to do the same treatment here but with `DefaultAS` instead. I'd say the third solution is to just put C-style casts everywhere, but that doesn't really work for classes as evidenced here.

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