[PATCH] A new HeapToStack allocation promotion pass

[Hal Finkel]

----- Original Message -----
> Hello,
> 
> I hope the idea of the patch wasn't abandoned, 

No; I'll get back to this next week. I'm going to try hacking up some 'returns normally' function attribute, with some handles-the-trivial-cases inference code. That will be a prerequisite to doing heap-to-stack sensibly without really castrating it (or committing a bunch of essentially dead code for handling functions).

> so here is another
> question: how do you handle stack deallocation? I notice that you
> mark the
> end of life of the alloca'd memory, but I wonder if llvm knows enough
> magic to handle that.

Yes, it should handle that in some correct way; whether and how stack deallocation happens, as far as I know, also depends on the capabilities in the backend (I think that the PowerPC backend, for example, does not deallocate anything until the end of the function -- stack coloring might help here, but I'm not sure). As you point out, if you convert dynamic allocations such that the total size is large, problems could result. I've not thought too much about the loop case; I'll experiment with it.

Thanks again,
Hal

> 
> For VLA, we save the stack pointer, allocate on the stack, and at the
> end
> of the scope we restore the stack pointer. This is possible in a
> large
> part because scopes in C cannot overlap unless one is included in the
> other. With malloc+free, we have no such guarantee:
> 
> p=malloc(m);
> q=malloc(n);
> free(p);
> free(q);
> 
> if at each free we tried to restore the frame pointer from the
> corresponding malloc, bad things would happen. Somehow we'd need to
> postpone that deallocation to some place that's pretty hard to define
> (that's where llvm may already have magic). The easiest seems to be
> not to
> deallocate, which also means removing the deallocations from true VLA
> that
> may already exist in the function. And it can easily overflow the
> stack if
> doing a stack allocation inside a loop.
> 
> --
> Marc Glisse
> 

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