[PATCH] A new HeapToStack allocation promotion pass

[Hal Finkel]

----- Original Message -----
> ----- 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."

After thinking about this, I've decided to make branching around the free the default behavior (although the old pointer-nulling behavior will still be available). Branching around the function call is probably cheaper than the function call itself. I'll be posting an updated patch soon.

Thanks again,
Hal

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