[PATCH] A new HeapToStack allocation promotion pass

Hal Finkel hfinkel at anl.gov
Tue Sep 24 08:25:14 PDT 2013


----- Original Message -----
> Hi,
> 
> |This should work correctly because it is testing the variables in
> |SSA form. Your example is really:
> 
> |int* p = malloc(<blah>);
> |<blah>
> |if (not_big_enough) {
> |    q = realloc(p,<blah>);
> |}
> |<blah>
> |r = phi(p, q)
> |free(r);
> 
> |and there is not a free of p on every path out of the function.
> 
> Thanks for clarifying that. That's the only case of a standard
> library function I can think of that is intended to be used to
> potentially "re-point" a pointer
> that otherwise has a within-function scope. I can't immediately see
> how a function along the lines of
> 
> hidden_realloc_ptr(int** p,int n) { free(*p); *p=malloc(n); }
> 
> used in place of the realloc() call above as
> 
> hidden_realloc_pointer(&p,<blah>)
> 
> would fare, but if that's handled without generating incorrect code
> then I think then the only snag I could think of isn't a problem.

I think this hidden_realloc_ptr case would also be okay. We have a couple of options:

 1. hidden_realloc_ptr is not inlined (or only trivially inlined) - In this case, mem2reg could not completely demote the address holding p to a local variable. The any free call in the function would be sourced by a load, and would not be paired with the original malloc.

 2. hidden_realloc_ptr is inlined, and so either both mallocs can be removed, or only the first one can, but the free in the caller cannot be removed, but is elided conditionally (by maybe setting the pointer to null).

Thanks again,
Hal

> 
> Cheers,
> Dave
> 
> 
> 
> 
> 

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



More information about the llvm-commits mailing list