libc++: First cut at <dynarray>

[Chandler Carruth]

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

>
> On Sep 12, 2013, at 10:51 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> > 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?"
>
> Ok.
>
> Sorry Marshall.  Great job, but hold off on the commit.  I think we need
> to sort this out.
>

Jumping up a few layers of context...

I'm actually fine checking in dynarray with a heap-only implementation. If
anything, so that we can demonstrate more fully that yes, we implemented
everything, and shockingly enough found problems. If the problems persuade
the committee to reconsider dynarray for C++14, wonderful. But it doesn't
seem unreasonable to track the draft as it progresses...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130912/f4563542/attachment.html>