[clang] [clang-tools-extra] [Clang] Use TargetInfo when deciding is an address space is compatible (PR #115777)

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> > Interesting, though reading through that I didn't see any mentions of implicit casts. It's simply stating that they can do casting if the target lists them as a subset.
> 
> That matches my understanding -- implicit or explicit casts require a subset relationship, as best I understand.

Okay, my generous interpretation is that it's fine for the compiler to use the target's information to determine if this is legal. So I updated the patch to use target information when making the decision.

> > Also it's worth noting that in the documentation it has stuff like __X char x, y, z which is a warning in clang due to how type level attributes work https://godbolt.org/z/Pfv36nEdq.
> 
> This is because the TR was written before we had attributes. AIUI, the TR is written with the idea that address spaces are specified via qualifiers (so more like `__global__`, for example). But the important bit is that the address space is a property of the type (and for `[[]]` attributes, there's specific syntactic requirements for where the attribute has to be written to apply to the type).

`__global__` is just `__attribute__((global))`, which works becuase `[[clang::global]] int x` also works, it just emits a warning because apparently that behavior was "deprecated" but not removed yet.

> > Maybe someone who reads better standardese than me can help with this. My ultimate goal is to make this legal when targeting NVPTX or AMDGPU, which is easily done by stating that DefaultAS is a superset of these other AS's. Let me know if making this target dependent is a good idea.
> > ```
> > void *foo(void [[clang::addrspace(3) *p) { return p; }
> > ```
> 
> Making sure I understand your example, you want a pointer in the generic address space to an object in address space three? As opposed to `void * [[clang::address_space(3)]] p` which would be a pointer in address space three to an object in the generic address space?

For AMDGPU and NVPTX, pointers are allowed to drop their address spaces transparently. So, `void AS(3) *` can convert to `void *`. Languages like CUDA and SYCL and HIP use these 'language' address spaces to describe exactly this, but my assertion is that it's more of a function of the target. I'm sure @arsenm could explain the underlying implementation more deeply.

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