libc++: First cut at <dynarray>
Hal Finkel
hfinkel at anl.gov
Thu Sep 12 21:21:40 PDT 2013
----- Original Message -----
>
>
>
>
> On Thu, Sep 12, 2013 at 9:04 PM, Hal Finkel < hfinkel at anl.gov >
> 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
More information about the cfe-commits
mailing list