<div dir="ltr">Hi <span style="font-size:14px">Mats</span>,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-31 17:51 GMT+08:00 Kevin Qin <span dir="ltr"><<a href="mailto:kevinqindev@gmail.com" target="_blank">kevinqindev@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, I classified `new (std::nothrow)` to be a malloc like allocation. See the next sentence.<br><div><span style="font-size:14px"><br></span><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">2015-03-31 17:48 GMT+08:00 mats petersson <span dir="ltr"><<a href="mailto:mats@planetcatfish.com" target="_blank">mats@planetcatfish.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> I think we can do such optimization with operator new, because new never returns null.<br>
<br>
</span>This is incorrect in the case of `new (std::nothrow) ...` - the whole<br>
point of `(std::nothrow)` is to tell new that it should return NULL in<br>
case of failure, rather than throw an exception (bad_alloc).<br>
<br>
But the point here is not the actual return value, but the fact that<br>
the compiler misses that the constructor has side-effects.<br>
<br>
--<br>
Mats<br>
<div><div><br>
<br>
<br>
On 31 March 2015 at 10:44, mats petersson <<a href="mailto:mats@planetcatfish.com" target="_blank">mats@planetcatfish.com</a>> wrote:<br>
> The optimisation here is that "nothing uses `m`, so we can assume<br>
> allocation works and remove the malloc + free pair".<br>
><br>
> What is the purpose of allocating 1 (or 100, or 1000000000) bytes,<br>
> never use it, and then free it immediately?<br>
><br>
> The test-code in the bug report does rely on the constructor being<br>
> called, and the bug here is probably [as I'm not familiar with the<br>
> workings of the compiler in enough detail] that it doesn't recognize<br>
> that the constructor has side-effects.<br>
><br>
> --<br>
> Mats<br>
><br>
> On 31 March 2015 at 10:24, Kevin Qin <<a href="mailto:kevinqindev@gmail.com" target="_blank">kevinqindev@gmail.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>><br>
>> When looking into the bug in <a href="https://llvm.org/bugs/show_bug.cgi?id=21421" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=21421</a>, I<br>
>> found a regression test in Transforms/InstCombine/malloc-free-delete.ll<br>
>> against me to directly fix it. The test is,<br>
>><br>
>> define i1 @foo() {<br>
>> ; CHECK-LABEL: @foo(<br>
>> ; CHECK-NEXT: ret i1 false<br>
>> %m = call i8* @malloc(i32 1)<br>
>> %z = icmp eq i8* %m, null<br>
>> call void @free(i8* %m)<br>
>> ret i1 %z<br>
>> }<br>
>><br>
>> According to <a href="http://www.cplusplus.com/reference/cstdlib/malloc/" target="_blank">http://www.cplusplus.com/reference/cstdlib/malloc/</a>, malloc may<br>
>> return null if this memory allocation fails. So why we assume malloc()<br>
>> always returns a non-null pointer here?<br>
>><br>
>> I think we can do such optimization with operator new, because new never<br>
>> returns null. But for all malloc like allocation(malloc, calloc, and new<br>
>> with std::nothrow), we shouldn't do this.<br>
>><br>
>> That regression test exists for a long time, I'm not sure if there's any<br>
>> special reason. Does anybody know about this?<br>
>><br>
>> --<br>
>> Thanks,<br>
>><br>
>> Kevin Qin<br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">Best Regards,<div><br></div><div>Kevin Qin</div></div></div>
</font></span></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>