----- Original Message ----- > ----- Original Message ----- > > > > > > Regarding the heap-to-stack: > > > > On Thu, Sep 12, 2013 at 9:21 PM, Hal Finkel < [email protected] > > > wrote: > > > > > > > > > > > > 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? > > > > > > > > Do you do it every time? If not, when? > > > > > > - What about when this dramatically increases stack usage > > (potentially causing us to run out of stack)? > > - What about cases where this occurs inside of a loop? Or is > > inlined > > into a loop? > > > > > > These are certainly solvable with reasonable thresholds, but > > setting > > those thresholds requires benchmarking across a wide variety of > > benchmarks, etc. Something that we should do, but something that is > > not trivial to do, and which I see zero chance of doing in 1 week. > > ;] > > > > > > Note that I didn't say "intractable", just "not trivial". I think > > that's the case. > > > > > > I have an initial implementation of the LLVM side of this. Hopefully > it will be ready to post for review in a few days. Then we can have > fun playing with all of the heuristics ;)
Posted for review: http://llvm-reviews.chandlerc.com/D1745 -Hal > > -Hal > > > > > > > And the dynamic case: > > > > > > > > > > > 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? > > > > > > > > This predates my work on the inliner. It has been there a *long* > > time. I don't know what the implications would be of removing it, > > that too would require benchmarking and analysis to ensure this > > doesn't regress code, or if it does to fix those regressions with > > more appropriate measures. > > > > > > >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. > > > > > > > > This is another threshold that I expect to be challenging to set > > and > > have be correct across a wide variety of architectures and > > benchmarks. > > > > > > > > This is somewhat of a chicken and egg problem. > > > > > > Not really. We have alloca and VLAs. We could use them, and can > > even > > build containers around them that aren't as elegant. And yet, I > > very > > rarely see code doing this in practice. > > -- > 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 > -- 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
