arsenm added a comment. In D151087#4360932 <https://reviews.llvm.org/D151087#4360932>, @jhuber6 wrote:
> 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. They bypass all semantic checks. For example if you declare something as address space 4, it will let you write to it unlike __constant__. It will let you place stack objects in globals and don't interact correctly with address space typed pointers in builtins (and any other context where you would want to interact with the matching language addrspace). Don't think sizeof works as you would expect either. Whatever is happening is not by design 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
