jhuber6 added a comment. In D151087#4360919 <https://reviews.llvm.org/D151087#4360919>, @arsenm wrote:
> In D151087#4360695 <https://reviews.llvm.org/D151087#4360695>, @jhuber6 wrote: > >> I don't think that's something we can diagnose here with just the address >> space number. it would require information from the underlying target for >> the expected pointer qualities to the address space. > > Yes, this is mandatory. Numbered address spaces are broken and just work by > accident and I don't love seeing new code rely on whatever random behavior > they have now. Right now they happen to codegen to something that appears to > work, while bypassing any kind of sensible semantic checking for what you're > doing with them. If you want to really use this, we need to find some way to > map numbers back into language address spaces and make them fully aware of > the target properties How are they broken? The expectation is just that they line up with what the backend defines them as, which should be a stable target. We could potentially use target info to map the numbered address spaces into something sensible. E.g. `1 = opencl_lobal`, `3 = opencl_local`, `5 = opencl_private`. I think that's commend between NVPTX and AMDGPU. But I still don't think that we should be preventing from even doing wrong things with them if the user explicitly requests it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151087/new/ https://reviews.llvm.org/D151087 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
