libc++: First cut at <dynarray>

[Chandler Carruth]

On Thu, Sep 12, 2013 at 6:23 PM, Howard Hinnant <howard.hinnant at gmail.com>wrote:

> Please commit with these changes, and thanks much.  Nice job!
>

I'm not sure it is worth it...


>
> Clang team:  If we don't have at least some stack support by Chicago, I
> may recommend removing dynarray for lack of implementation experience.  I'm
> seeking feedback from the clang team on that course of action.  If I hear
> from you that such support is no problem and I'm just being a nervous
> nanny, I'll back down.  But if we're still figuring out how to do this, and
> no one else has either, then color me nervous nanny.  dynarray is not
> worthy of standardization without stack support.
>

Speaking from both the Clang and LLVM side: I don't think we know what we
want to have to put things on the stack, and I am confident we won't have
it by Chicago. There are big, nasty, hard to answer questions in the space
of compiler-aided variable sized stack allocation. Currently on x86 with
LLVM, if the size is variable and you have a reasonably fast malloc
library, putting dynarray on the stack will often be a pessimization. I'm
not sure how often we can make variable sized stack allocation the right
choice, but it will at the least require some reasonably significant
changes to LLVM's optimizer itself.

Even then, I currently expect that small vector, or a standard allocator
that pulls initially from a fixed-size stack-based pool, will be
significantly faster, and the only reason for having dynarray at all was
performance! Considering how hard it is to implement, I'm inclined
currently to go back to the committee with the lesson "it's really hard,
and it won't even be faster. can we just stick with vector?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130912/5aa0ec43/attachment.html>