libc++: First cut at <dynarray>

[Hal Finkel]

----- Original Message -----
> ----- Original Message -----
> > 
> > 
> > Regarding the heap-to-stack:
> > 
> > On Thu, Sep 12, 2013 at 9:21 PM, Hal Finkel < hfinkel at anl.gov >
> > 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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 

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