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

[mats petersson]

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
>