On Thu, Sep 12, 2013 at 9:04 PM, Hal Finkel <[email protected]> wrote: > > The best approach that I have found is: > > * Implement a general heap-to-stack optimization for LLVM > > I'm completely on-board with this. >
It's not trivial to implement though, and even if we implement it (and I do want one!)... > > > * Add metadata on a call that LLVM recognizes as an allocation > > function (eg, _Znwm or malloc) that says "try to promote this to the > > stack, even if the allocation size is not constant" > > This seems like a simple addition to the first option, allowing the user > to override the cost model, right? I imagine that we might want to keep the > malloc calls if the cost of the code in between the malloc and free is high > (on the assumption that it is better not to unnecessarily increase register > pressure by introducing dynamic allocations). This metadata would just tell > the optimizer to do the transformation whenever legal. Is that the idea? But I'm really unsure when (if ever) we will *actually* want to move to the stack.... It blocks inlining, increases register pressure, etc... I just don't see a real demand for it.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
