[LLVMdev] Constant folding inttoptr i32 0 to null pointer?

[Daniel Berlin]

Yes.


On Tue, Jun 9, 2015 at 1:01 PM, Benyei, Guy <guy.benyei at intel.com> wrote:
> Well, address 0 is pretty well aligned for whatever alignment we like.
>
> So I understand, that “load volatile i32, i32 addrspace(1)* null” is a valid
> memory access, accessing address 0?
>
>
>
> Thanks
>
>       Guy
>
>
>
> From: David Majnemer [mailto:david.majnemer at gmail.com]
> Sent: Tuesday, June 09, 2015 22:55
>
>
> To: Benyei, Guy
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Constant folding inttoptr i32 0 to null pointer?
>
>
>
>
>
>
>
> On Tue, Jun 9, 2015 at 12:32 PM, David Majnemer <david.majnemer at gmail.com>
> wrote:
>
> 'load volatile i32 addrspace(1)* null' seems fine to me.  However, it looks
> like instcombine will turn:
>
> define i32 @foo() {
>
> entry:
>
>   %std_ld.i = load volatile i32, i32 addrspace(1)* null
>
>   ret i32 %std_ld.i
>
> }
>
>
>
> into:
>
> define i32 @foo() {
>
> entry:
>
>   %std_ld.i = load volatile i32, i32 addrspace(1)* null, align 536870912
>
>   ret i32 %std_ld.i
>
> }
>
>
>
> which is not ok.
>
>
>
> On second thought, I think that high alignment is benign.  It simply
> indicates that your backend is free to load the value as-if it were aligned
> to an arbitrary boundary (because it is 1 byte, 2 byte, 4 byte, etc.
> aligned).
>
>
>
>
>
> On Tue, Jun 9, 2015 at 11:34 AM, Benyei, Guy <guy.benyei at intel.com> wrote:
>
> Thanks David,
>
> It turns out, that the address space I was using was not 0, and yet the
> pointer was constant folded to null.
>
>
>
> Here is the sequence:
>
>
>
> Unoptimized code:
>
>
>
> define i32 @foo() #0 {
>
> entry:
>
>   %address.addr.i = alloca i32, align 4
>
>   %value.i = alloca i32, align 4
>
>   store i32 0, i32* %address.addr.i, align 4
>
>   %0 = load i32* %address.addr.i, align 4
>
>   %1 = inttoptr i32 %0 to i32 addrspace(1)*
>
>   %std_ld.i = load volatile i32 addrspace(1)* %1
>
>   store i32 %std_ld.i, i32* %value.i, align 4
>
>   %2 = load i32* %value.i, align 4
>
>   ret i32 %2
>
> }
>
>
>
> After optimization (early CSE):
>
>
>
> define i32 @foo() #0 {
>
> entry:
>
>   %std_ld.i = load volatile i32 addrspace(1)* null, align 536870912
>
>   ret i32 %std_ld.i
>
> }
>
>
>
> The contant folder doesn’t seem to check for address space, it simply checks
> if the integer in question is zero, and folds the inttoptr to null:
>
>
>
> Constant *llvm::ConstantFoldCastInstruction(unsigned opc, Constant *V,
>
>                                             Type *DestTy) {
>
>
>
> ...
>
>
>
>   if (V->isNullValue() && !DestTy->isX86_MMXTy())
>
>     return Constant::getNullValue(DestTy);
>
> ...
>
>
>
>
>
> Is this a bug?
>
>
>
> Thanks
>
>      Guy
>
>
>
>
>
>
>
> From: David Majnemer [mailto:david.majnemer at gmail.com]
> Sent: Tuesday, June 09, 2015 18:45
> To: Benyei, Guy
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Constant folding inttoptr i32 0 to null pointer?
>
>
>
>
>
>
>
> On Tue, Jun 9, 2015 at 5:57 AM, Benyei, Guy <guy.benyei at intel.com> wrote:
>
> Hello,
>
> It seems that ConstantFoldCastInstruction in ConstantFold.cpp folds inttoptr
> instruction with 0 as operand to a null pointer. It makes sense, when
> talking about a C-style frontend, as the C99 spec (6.3.2.3) states:
>
>
>
> “An integer constant expression with the value 0, or such an expression cast
> to type void *, is called a null pointer constant.”
>
>
>
> On the other hand, some architectures use 0 as a valid memory location, and
> this constant folding seems to be possibly harmful when the code actually
> tries to access the memory location at address 0.
>
> Is this behavior intentional? Do I miss something? Will a load from address
> null try to access address 0, or may it become an undef value?
>
>
>
> LLVM assumes that the null pointer in address space zero can never be
> successfully dereferenced.  You must utilize some other address space to
> dereference a null pointer.
>
>
>
>
>
> Thanks
>
>        Guy
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>