libc++: First cut at <dynarray>

[Hal Finkel]

----- 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.
> 

Okay, agreed.

> 
> 
> 
> 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.

Yes, although if there are very few users as you say, then there will not be too much benchmarking to do ;)

> 
> 
> >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.

I'm not sure about this. How can you build a container around those? The motivation, as I understand it, for dynarray (or something like it) was exactly that people *want* to do this, but can't without compiler support.

 -Hal

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