rjmccall added a comment. In https://reviews.llvm.org/D26196#587135, @yaxunl wrote:
> In https://reviews.llvm.org/D26196#586433, @rjmccall wrote: > > > I think there are a number of conceptual questions here, chiefly among them > > whether an llvm::ConstantPointerNull in an address-space type should have > > the correct representation for the target. If the decision for that is > > "no", then ok, we can produce an explicit representation in IRGen; however, > > we will need to update quite a bit of code in order to do so correctly. > > > As Tom and Matt pointed out, llvm::ConstantPointerNull is the desired > representation for a null pointer. However, currently LLVM assumes that it > has 0 value extensively, and there is no plan to change that in a foreseeable > future. This patch is intended to provide a workaround for this restriction > by representing non-zero null pointer in an alternative way. Yes, I understand the goal of this patch, and I am fine with working around the LLVM limitation in the frontend. I will, however, point out that Clang's assumptions about the representation of null are not necessarily any less extensive than LLVM's. >> In general, frontend address spaces don't necessarily correspond to IR >> address spaces. All of your address-space operations need to be >> parameterized with a frontend address space (or both a source and dest >> address space for conversions). The question you should be keeping in mind >> when designing these APIs is "what if there were an address space defined to >> be exactly the generic address space, only with a different null value?" > > Since non-zero null pointer is usually resulted from target restrictions (as > in the case of amdgpu target), whether a null pointer needs a special > representation only depends on the target or IR address space. Therefore we > do not need to consider the address space in the source language. Hopefully > this can simplify the implementation. Please do as I laid out and base this decision on the source-language address space. It will not significantly complicate the implementation. https://reviews.llvm.org/D26196 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
