libc++: First cut at <dynarray>

[Chandler Carruth]

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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130912/12350299/attachment.html>