[PATCH] A new HeapToStack allocation promotion pass

[Hal Finkel]

----- Original Message -----
> ----- Original Message -----
> > (I am not on the list)
> > 
> > > 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.).
> > 
> > Hello,
> > 
> > this seems to rely on the fact that 'bar' returns normally, and
> > thus
> > that
> > whenever malloc is executed, free will be as well. However, bar
> > could
> > never return, or return abnormally by throwing an exception which
> > will
> > skip the call to free.
> > 
> > void bar(int *x) {
> >    free(x);
> >    throw 42;
> > }
> > 
> > will result in calling free on the stack. Now if there was a
> > destructor
> > calling free in foo1... Do you actually also consider exceptions
> > when
> > you
> > test that all paths from malloc to the exits contain a call to
> > free?
> > That
> > would only leave noreturn functions.
> 
> Marc,
> 
> Thanks!
> 
> My understanding is that the extra control-flow from exception
> handling should be accounted for by the basic-block
> successor/predecessor information (because calling a function that
> might throw uses invoke, and then you see both the regular
> predecessor and the cleanup block as predecessors). I'll
> double-check that's correct. Also, you're right, I should check the
> function's does-not-return attribute also.

To be slightly more specific on this last point, there is some pass that inserts 'unreachable' after such functions, but I should make sure that we always run after it (or deal with it internally).

 -Hal

> 
>  -Hal
> 
> > 
> > --
> > Marc Glisse
> > 
> 
> --
> 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