libc++: First cut at <dynarray>

[Hal Finkel]

----- Original Message -----
> 
> 
> 
> 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?"

Not to be argumentative ;) -- but I strongly disagree. Good pool allocators are very fast, granted, but tend to add extra memory overhead which, in some environments, is hard to justify (I'm speaking from personal experience here). Having dynamic stack allocation in C++ would be a great step forward.

Furthermore, I don't why this would not be trivial to implement:

 1. We add an intrinsic, like alloca, called alloca_in_caller. This is only allowed in functions marked always_inline.
 2. To the analysis passes, alloca_in_caller looks like malloc
 3. When the inliner inlines a alloca_in_caller call, it transforms it into an alloca call

(and that's it I think). Perhaps I'm way off base, but it seems fairly simple. Is there anything else that's needed?

Thanks again,
Hal

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