<br><div class="gmail_quote">2011/9/12 Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca">nicholas@mxc.ca</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div>LLVM could figure out that there is no "below the pointer" by noticing that the object came from malloc. I think the missing optimization here is a heap->stack transform.<br></div></blockquote>
<div><br>That sounds good for me. I myself have to concentrate on the compiler, so I dont have so much time to implement one of these things on my own in the near future. <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

I note that in your example the exit is not post-dominated by free(). The transform could still fire by noticing that the pointer returned by malloc never escaped the function. (A more expensive check would be to see that it never escaped the function along the path that didn't call free. This is related to <a href="http://llvm.org/PR8908#c1" target="_blank">http://llvm.org/PR8908#c1</a> .)<br>
</blockquote><div><br>But the pointer left the function. The pointer was sent to puts (not the pointer itself, but a getelementptr of it). I think, the best way would be to do a heap->stack when malloc and free are in the same control flow.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
One other thing we may want is a flag for "does not care about the pointer itself, only what the pointer points to". Currently, nothing tells LLVM that puts() doesn't check whether the pointer argument == &string_00000001, so we can't actually remove the copy. We could special-case that optimization into SimplifyLibCalls.<br>
<font color="#888888">
<br>
Nick<br>
</font></blockquote></div><br>But: A heap->stack optimization would not remove the mem copying. The parameter flags to determine a zero extended string are still needed.<br>