yaxunl added a comment. 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. > 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. https://reviews.llvm.org/D26196 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
