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

[Jiangning Liu]

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150401/77a143bd/attachment.html>