[PATCH] A new HeapToStack allocation promotion pass

Hal Finkel hfinkel at anl.gov
Sun Sep 29 10:59:15 PDT 2013


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

This seems to be a bug in DSE. I've opened PR17405 on this.

 -Hal

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

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



More information about the llvm-commits mailing list