[PATCH] A new HeapToStack allocation promotion pass

[Hal Finkel]

----- Original Message -----
> 
> 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 could. The reason that I didn't is because this way the transformation does not cause any CFG changes. C/POSIX say, "If ptr is a null pointer, no action occurs."

 -Hal

> 
> 
> 
> 
> 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
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory