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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
