[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
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
-------------- 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