[PATCH] D26196: Add support for non-zero null pointer for C and OpenCL

[John McCall via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D26196#602660, @yaxunl wrote:

> > But if you do need to support these conversions for some reason, the correct behavior is to ensure that null is mapped to null.
>
> I only need to do this for constant folding, right? I found that the current implementation is already able to cast null pointer to the correct representation of null pointer in another address space for constant expression. e.g. file-scope variables
>
>   generic char *gen = (global char*)(generic char*)(private char*)0;
>   private char *priv = (private char*)(generic char*)(global char*)0;
>   global char *glob = (global char*)(generic char*)(global char*)0;
>  
>  
>
>
> are translated to
>
>   @gen = addrspace(1) global i8 addrspace(4)* null, align 4
>   @priv = addrspace(1) global i8* addrspacecast (i8 addrspace(4)* null to i8*), align 4
>   @glob = addrspace(1) global i8 addrspace(1)* null, align 4
>
>
> This is because null pointers are handled in APValue and PointerExprEvaluator::VisitCastExpr. Once a null pointer is identified, it can survive passing through addrspacecast and bitcast. When it gets folded, it becomes the target-specific null pointer representation in the target address space.
>
> However, if an addrspacecast is not going through constant folding, it will be translated to LLVM addrspacecast, e.g.
>
>   void test_cast(void) {
>     global char* glob = (global char*)(generic char*)0;
>    }
>
>
> Since the initializer of the function-scope variable does not go through constant folding, it is not translated to target-specific null pointer representation in the target address space. Instead, it is simply an addrspacecast of the original null pointer:
>
>   define void @test_cast() #0 {
>   entry:
>     %glob = alloca i8 addrspace(1)*, align 4
>     store i8 addrspace(1)* addrspacecast (i8 addrspace(4)* null to i8 addrspace(1)*), i8 addrspace(1)** %glob, align 4
>     ret void
>   }
>
>
> This is still correct translation, since backend should be able to understand addrspacecast of null pointer.
>
> Do you think in the last case I should try to fold the addrspacecast?


Yes.  I think it would be wrong for an addrspacecast of a literal llvm::ConstantPointerNull to have different semantics from an addrspacecast of an opaque value that happens to be an llvm::ConstantPointerNull.


https://reviews.llvm.org/D26196