[LLVMdev] Constant folding inttoptr i32 0 to null pointer?
Daniel Berlin
dberlin at dberlin.org
Tue Jun 9 13:22:31 PDT 2015
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
>
More information about the llvm-dev
mailing list