David Majnemer
2015-Jun-09 19:54 UTC
[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. >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150609/dfa9e70c/attachment.html>
Benyei, Guy
2015-Jun-09 20:01 UTC
[LLVMdev] Constant folding inttoptr i32 0 to null pointer?
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<mailto: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<mailto: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<mailto:david.majnemer at gmail.com>]
Sent: Tuesday, June 09, 2015 18:45
To: Benyei, Guy
Cc: llvmdev at cs.uiuc.edu<mailto: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<mailto: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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150609/abd0bab5/attachment.html>
Daniel Berlin
2015-Jun-09 20:22 UTC
[LLVMdev] Constant folding inttoptr i32 0 to null pointer?
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 >