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

[David Majnemer]

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>