yaxunl added a comment. In https://reviews.llvm.org/D35082#890150, @rjmccall wrote:
> Non-canonical information is not supposed to be mangled. > > It's not clear to me what the language rule you're really trying to implement > is. Maybe you really do need a canonical __private address space, in which > case you are going to have to change a lot of code in Sema to add the address > space qualifier to every local and temporary allocation. But that's not > obvious to me yet, because you haven't really explained why it needs to be > explicit in the representation. In OpenCL all memory is in certain address space, therefore every l-value and pointee in a pointer should have an address space. Private address space has equal status as global or local address space. There are language rules about pointers to what address space can be assigned to pointers to what address space. Therefore all address space needs to be canonical. This patch already puts every local variable and function parameter in private address space, as is done in deduceOpenCLImplicitAddrSpace(). We need private address space to be explicit because we need to display explicit private address space and implicit address space differently, also because in certain semantic checks we need to know if a private address space is explicit or not. > If you just want pointers to __private to be mangled with an address-space > qualifier — meaning I guess that the mangling e.g. Pi will be completely > unused — that should be easy enough to handle in the mangler. But if you > need to distinguish between __private-qualified types and unqualified types, > and that distinction isn't purely to implement some syntactic restriction > about not writing e.g. __private __global, then that's not good enough and > you do need a canonical __private. The mangler does not mangle an empty type qualifier, therefore if private address space is represented as the default address space (i.e., no address space), it will not be mangled at all. This is also related to the substitution and cannot be easily changed without breaking lots of stuff in the mangler. > Telling me that you're in a hurry isn't helpful; preserving a reasonable > representation and not allowing corner cases to become maintenance problems > is far more important to the project than landing patches in trunk on some > particular schedule. The introduction of explicit private address space and the implicit address space flag in AST is precisely for handling those corner cases in the OpenCL language rules so that they won't become maintenance problems. https://reviews.llvm.org/D35082 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
