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

[David Majnemer]

'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 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150609/2504cf86/attachment.html>