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

Kevin Qin kevinqindev at gmail.com
Tue Mar 31 02:24:50 PDT 2015


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?


Kevin Qin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150331/e1d0a4f4/attachment.html>

More information about the llvm-dev mailing list