----- Original Message ----- > > > > > 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!)...
Me too; why is it not simple: - For all calls to malloc, for which we see calls to free along all control-flow paths - Replace the malloc with alloca, remove the free (and add lifetime intrinsics immediately after the alloca and where the free used to be) What am I missing? > > > > > > * 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, Only because you made it do so; we could enabling inlining just as easily. When you originally did this, we did not have stack coloring, right? >increases register pressure, This is true, but it is not clear that it would be a significant problem. Function calls have overhead too, obviously, so I think that for small functions it would probably be okay, and for larger functions you'd probably want to maintain the prohibition. > etc... > I just don't see a real demand for it. This is somewhat of a chicken and egg problem. -Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
