<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 23, 2013 at 2:00 PM, <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi chandlerc,<br>
<br>
This adds a new optimization pass that can 'promote' malloc'd memory to stack-allocated memory when the lifetime of the allocation can be determined to be bounded by the execution of the function.<br>
<br>
To be specific, consider the following three cases:<br>
<br>
void bar(int *x);<br>
<br>
void foo1() {<br>
  int *x = malloc(16);<br>
  bar(x);<br>
  free(x);<br>
}<br>
<br>
In this case the malloc can be replaced by an alloca, and the free removed. Note that this is true even though the pointer 'x' is definitely captured (and may be recorded in global storage, etc.).<br>
<br>
The pairing between the malloc and the free need not be 1:1, for example:<br>
<br>
void foo2(int a) {<br>
  int *x;<br>
<br>
  if (a == 0)<br>
    x = malloc(16);<br>
  else<br>
    x = malloc(32);<br>
<br>
  bar(x);<br>
  free(x);<br>
}<br>
<br>
where both mallocs and the free can be removed, and, finally, the free might not exclusively be used to free stack-promotable allocations, as in:<br>
<br>
void foo3(int *y) {<br>
  if (y == 0)<br>
    y = malloc(48);<br>
<br>
  bar(y);<br>
  free(y);<br>
}<br>
<br>
to handle this last case, which is referred to as an 'ambiguous' free in the code, a new boolean value is introduced to track the source of the allocation. The malloc is removed, but the free is not. Instead, the pointer passed to the free is conditionally set to null to prevent freeing a stack address.<br>
</blockquote><div><br></div><div>I don't believe free is guaranteed to be a no-op on null (I believe it's undefined), unlike C++ delete (which is defined to no-op on null). Should this instead make the whole call conditional, rather than the argument?</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I talked briefly to Chandler about this offline, and we might want to turn the core functionality here into a utility function so that it can be used directly by SROA. Nevertheless, I think that the basic functionality can be reviewed in this form, and I'd like to discuss any other desired refactoring as part of the review process.<br>

<br>
Note: Using this pass causes a miscompile in SingleSource/Benchmarks/Shootout/objinst -- the transformation performed by HeapToStack looks valid, and bugpoint attributes the failure to some combination of later transformations. I'll open a separate bug report to track this issue.<br>

<br>
Please review and thanks again!<br>
<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D1745" target="_blank">http://llvm-reviews.chandlerc.com/D1745</a><br>
<br>
Files:<br>
  include/llvm-c/Transforms/Scalar.h<br>
  include/llvm/IR/DataLayout.h<br>
  include/llvm/InitializePasses.h<br>
  include/llvm/LinkAllPasses.h<br>
  include/llvm/Transforms/Scalar.h<br>
  lib/Transforms/IPO/PassManagerBuilder.cpp<br>
  lib/Transforms/Scalar/CMakeLists.txt<br>
  lib/Transforms/Scalar/HeapToStack.cpp<br>
  lib/Transforms/Scalar/Scalar.cpp<br>
  test/Transforms/HeapToStack/basic.ll<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>