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

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> Which is the gist of what I am saying: linguistic constructs carry semantics (meaning), we should not work back from their disembodied lowering into a target specific quantity to generalise the latter into a linguistic construct beyond the initial one. CUDA made language design choices, it is an AS agnostic language, cuda_shared doesn't work like an address space in the OCL / Clang sense, even though it ends up lowered through the same mechanism / leads to a numbered AS being CodeGen-ed. TL;DR: this doesn't work by design, not by accident = those ARE distinct from a language perspective.

I've updated this to make the language AS's and target AS's so now this won't conflict at all. This patch just uses target information to ascribe some semantic meaning to the target AS's, which I believe is legitimate. The text that @AaronBallman provided says the following.

>If a pointer into address space A is assigned to a pointer into a different address space B, a
constraint requires that A be a subset of B. (As usual, this constraint can be circumvented by a cast
of the source pointer before the assignment.)
... 
For every pair of distinct address spaces A and B, it is implementation-defined whether A
encloses B.
..
If one address space encloses another, the two address spaces overlap, and their combined
address space is the one that encloses the other. If two address spaces do not overlap, they are

My interpretation of this is that it's fine to have target specific behavior for address spaces, and that it seems okay with `B = A` if we say they're subsets (which they are for this target).
disjoint, and no location (address) within one is also within the other. (Thus if two address spaces
share a location, one address space must enclose the other.)

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