[clang] [lld] [llvm] [mlir] [IR] Introduce `T<address space>` to `DataLayout` to represent flat address space if a target supports it (PR #108786)

[Alex Voicu via cfe-commits]

AlexVlx wrote:

> I updated the PR description. Hopefully it can make the motivation of this patch more clear. I think the central question is, why it can't be just address space 0. I don't have a clear answer to that. @arsenm first introduced this concept to LLVM at least 8 years ago. I agree that the only two targets that have this concept are AMDGPU and NVPTX, and they both set it to address space 0. My understanding is, LLVM doesn't force any other characteristics to address 0 in addition to just making it as the default one if there is no other specified for the allocation of certain variables, so we can't assert or assume how a target needs to implement it.

There are targets that use a different integer to denote flat (e.g. see SPIR & SPIR-V). Whilst I know that there are objections to that, the fact remains that they had historical reason (wanted to make legacy OCL convention that the default is private work, and given that IR defaults to 0 this was an easy, if possibly costly, way out; AMDGPU also borks this for legacy OCL reasons, which has been a source of pain). I think the core matter, which we also talked about in #95728, is that LLVM defaults to 0 and posits some guarantees around that as per LangRef, but it doesn't say much of anything about guaranteed convertibility to / from 0. Which turns out to be a problem for targets / pseudo-targets which do not also use 0 to denote flat/generic, as a number of constructs that merely rely on getting the default end up needing a cast. @efriedma-quic made the point that in general there should / would always be a correct AS and the solution is to emit these in the right AS from the get-go, but the problem is somewhat pervasive.

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