[LLVMdev] why we assume malloc() always returns a non-null pointer in instruction combing?

[David Majnemer]

On Tue, Mar 31, 2015 at 7:59 PM, Jiangning Liu <liujiangning1 at gmail.com>
wrote:

> Hi Mats,
>
> I think Kevin's point is malloc can return 0, if malloc/free pair is
> optimized way, the semantic of the original would be changed.
>
> On the other hand, malloc/free are special functions, but programmers can
> still define their own versions by not linking std library, so we must
> assume malloc/free always have side-effect like other common functions,
> unless we know we will link std library only at link-time.
>

If programmers want to do this, they need to compile their program with
-ffreestanding.


>
> Thanks,
> -Jiangning
>
>
> 2015-03-31 17:51 GMT+08:00 Kevin Qin <kevinqindev at gmail.com>:
>
>> Yes, I classified `new (std::nothrow)` to be a malloc like allocation.
>> See the next sentence.
>>
>>
>> 2015-03-31 17:48 GMT+08:00 mats petersson <mats at planetcatfish.com>:
>>
>>> > I think we can do such optimization with operator new, because new
>>> never returns null.
>>>
>>> This is incorrect in the case of `new (std::nothrow) ...` - the whole
>>> point of `(std::nothrow)` is to tell new that it should return NULL in
>>> case of failure, rather than throw an exception (bad_alloc).
>>>
>>> But the point here is not the actual return value, but the fact that
>>> the compiler misses that the constructor has side-effects.
>>>
>>> --
>>> Mats
>>>
>>>
>>>
>>> On 31 March 2015 at 10:44, mats petersson <mats at planetcatfish.com>
>>> wrote:
>>> > The optimisation here is that "nothing uses `m`, so we can assume
>>> > allocation works and remove the malloc + free pair".
>>> >
>>> > What is the purpose of allocating 1 (or 100, or 1000000000) bytes,
>>> > never use it, and then free it immediately?
>>> >
>>> > The test-code in the bug report does rely on the constructor being
>>> > called, and the bug here is probably [as I'm not familiar with the
>>> > workings of the compiler in enough detail] that it doesn't recognize
>>> > that the constructor has side-effects.
>>> >
>>> > --
>>> > Mats
>>> >
>>> > On 31 March 2015 at 10:24, Kevin Qin <kevinqindev at gmail.com> wrote:
>>> >> Hi,
>>> >>
>>> >>
>>> >> When looking into the bug in
>>> https://llvm.org/bugs/show_bug.cgi?id=21421, I
>>> >> found a regression test in
>>> Transforms/InstCombine/malloc-free-delete.ll
>>> >> against me to directly fix it. The test is,
>>> >>
>>> >> define i1 @foo() {
>>> >> ; CHECK-LABEL: @foo(
>>> >> ; CHECK-NEXT: ret i1 false
>>> >>   %m = call i8* @malloc(i32 1)
>>> >>   %z = icmp eq i8* %m, null
>>> >>   call void @free(i8* %m)
>>> >>   ret i1 %z
>>> >> }
>>> >>
>>> >> According to http://www.cplusplus.com/reference/cstdlib/malloc/,
>>> malloc may
>>> >> return null if this memory allocation fails. So why we assume malloc()
>>> >> always returns a non-null pointer here?
>>> >>
>>> >> I think we can do such optimization with operator new, because new
>>> never
>>> >> returns null. But for all malloc like allocation(malloc, calloc, and
>>> new
>>> >> with std::nothrow), we shouldn't do this.
>>> >>
>>> >> That regression test exists for a long time, I'm not sure if there's
>>> any
>>> >> special reason. Does anybody know about this?
>>> >>
>>> >> --
>>> >> Thanks,
>>> >>
>>> >> Kevin Qin
>>> >>
>>> >> _______________________________________________
>>> >> LLVM Developers mailing list
>>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>> >>
>>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> Kevin Qin
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150331/efb30d4e/attachment.html>