<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div></div><br><div><div>On Jan 2, 2013, at 11:15 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div class="gmail_default" style="">I really do share Nick's concern.</div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">
I would be fine doing this in -Oz mode, where hurting performance for code size is the goal, but outside of that I'm deeply skeptical that we have enough information to make the right decision here.</div><div class="gmail_default" style="">
<br></div><div class="gmail_default" style="">There are code patterns where the pointer is almost-always null. Imagine a sparsely populated vector of pointers. In this case, there will be a hot loop where you are turning a highly predictable branch into a function call.</div>
<div class="gmail_default" style=""><br></div><div class="gmail_default" style="">We could use various "hotness" heuristics from the BlockFrequencyInfo to control this optimization, but honestly I think the only one that we won't find to pessimize real world code is "very cold" relative to the function entry block.</div>
<div class="gmail_default" style=""><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 2, 2013 at 10:18 AM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank" class="cremed">qcolombet@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Ping!<span class="HOEnZb"><font color="#888888"><br><div>
<div style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-wrap:break-word;word-spacing:0px">
-Quentin</div>
</div>
<div><br></div><div></div></font></span></div>
<br><div style="word-wrap:break-word"><div></div><br><div><div>On Dec 21, 2012, at 4:04 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank" class="cremed">qcolombet@apple.com</a>> wrote:</div>
<br><blockquote type="cite">Hi Nick,<br><br>On Dec 21, 2012, at 3:59 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank" class="cremed">gribozavr@gmail.com</a>> wrote:<br><br><blockquote type="cite">
On Sat, Dec 22, 2012 at 1:53 AM, Nick Lewycky <<a href="mailto:nicholas@mxc.ca" target="_blank" class="cremed">nicholas@mxc.ca</a>> wrote:<br><blockquote type="cite">On 12/21/2012 03:43 PM, Quentin Colombet wrote:<br>
<blockquote type="cite"><br>Hi,<br><br>Here is a patch to help llvm turning a code like this:<br>if (foo)<br>free(foo)<br><br>into that:<br>free(foo)<br><br>It is legal and safe, since free is already checking its argument<br>
against NULL internally (I may find the reference in the Standard if<br>needed :)).<br></blockquote><br>It's legal and safe, but is it desirable? Calling a function is expensive<br>even if the function doesn't do anything.<br>
</blockquote></blockquote><br>Yes, you're right, it may not be desirable but I'm tempt to think like Dmitri.<br><br>Do you think that this optimization should be controlled by a flag?<br>At least, for code size (Oz and maybe Os), it may always be desirable.<br>
<br>I did not consider changing free(foo) into if(foo) free(foo)<br><br><blockquote type="cite"><br>That's true, but there's another viewpoint: programmers usually write<br>'if(!foo) free(foo);' not because they are manually inlining the fast<br>
path of free(), but because they think that free(NULL) is UB.<br><br>Dmitri<br><br>-- <br>main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank" class="cremed">gribozavr@gmail.com</a>>*/<br>
</blockquote><br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" class="cremed">llvm-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></body></html>