<div dir="ltr">Hi,<div><br></div><div><br></div><div>When looking into the bug in <a href="https://llvm.org/bugs/show_bug.cgi?id=21421">https://llvm.org/bugs/show_bug.cgi?id=21421</a>, I found a regression test in Transforms/InstCombine/malloc-free-delete.ll against me to directly fix it. The test is,</div><div><br></div><div><div>define i1 @foo() {</div><div>; CHECK-LABEL: @foo(</div><div>; CHECK-NEXT: ret i1 false</div><div>  %m = call i8* @malloc(i32 1)</div><div>  %z = icmp eq i8* %m, null</div><div>  call void @free(i8* %m)</div><div>  ret i1 %z</div><div>}</div><div><br></div><div>According to <a href="http://www.cplusplus.com/reference/cstdlib/malloc/">http://www.cplusplus.com/reference/cstdlib/malloc/</a>, malloc may return null if this memory allocation fails. So why we assume malloc() always returns a non-null pointer here?</div><div><br></div><div>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.</div><div><br></div><div>That regression test exists for a long time, I'm not sure if there's any special reason. Does anybody know about this?<br></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Thanks,<div><br></div><div>Kevin Qin</div></div></div>
</div></div>