[PATCH] A new HeapToStack allocation promotion pass

[David Blaikie]

On Mon, Sep 23, 2013 at 2:00 PM, hfinkel at anl.gov <hfinkel at anl.gov> wrote:

> Hi chandlerc,
>
> 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.
>
> To be specific, consider the following three cases:
>
> void bar(int *x);
>
> void foo1() {
>   int *x = malloc(16);
>   bar(x);
>   free(x);
> }
>
> 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.).
>
> The pairing between the malloc and the free need not be 1:1, for example:
>
> void foo2(int a) {
>   int *x;
>
>   if (a == 0)
>     x = malloc(16);
>   else
>     x = malloc(32);
>
>   bar(x);
>   free(x);
> }
>
> 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:
>
> void foo3(int *y) {
>   if (y == 0)
>     y = malloc(48);
>
>   bar(y);
>   free(y);
> }
>
> 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.
>

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?


>
> 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.
>
> 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.
>
> Please review and thanks again!
>
>
> http://llvm-reviews.chandlerc.com/D1745
>
> Files:
>   include/llvm-c/Transforms/Scalar.h
>   include/llvm/IR/DataLayout.h
>   include/llvm/InitializePasses.h
>   include/llvm/LinkAllPasses.h
>   include/llvm/Transforms/Scalar.h
>   lib/Transforms/IPO/PassManagerBuilder.cpp
>   lib/Transforms/Scalar/CMakeLists.txt
>   lib/Transforms/Scalar/HeapToStack.cpp
>   lib/Transforms/Scalar/Scalar.cpp
>   test/Transforms/HeapToStack/basic.ll
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130923/d7cf638f/attachment.html>