libc++: First cut at <dynarray>

[Marshall Clow]

[ I've tried to make the attributions clear. If I've messed up who said what, I apologize - and please let me know ]

On Sep 12, 2013, at 8:19 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>> On Thu, Sep 12, 2013 at 6:23 PM, Howard Hinnant <howard.hinnant at gmail.com > wrote:
>> 
>>> Howard> Please commit with these changes, and thanks much. Nice job!
>> 
>> 
>> Chandler> I'm not sure it is worth it...
>> 
>>> Howard> 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.
>> 
>> Chandler> 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.
>> 
>> Chandler> 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?

I've been talking to Nick and to Richard over the last week, and I think we need more than just an alloca.
The compiler needs to decide when to put stuff on the stack.

Consider the following code:
	typedef std::dynarray<long> dArray;

	{
	dArray arr1 ( 6 );
	// some code that uses arr1
	}

The six longs that make up dynarray really belong on the stack.

	{
	return new dArray ( 6 );
	}

These six longs cannot be put on the stack. When would they be deallocated?

(There's a third case, where a dynamic array is a member variable in a class or struct, but I think these two cover it well enough)

In the discussion with Nick and Richard, we came up with the idea of a compiler intrinsic that is a hint, (i.e try to put this allocation on the stack), and then, if during the compiler's optimization pass, it decides that it has enough information (i,e can see the whole lifetime of the dynarray, etc), then it can change the allocation (call to ::operator new) to a call to something like alloca. [ Same, obviously for deallocation ]

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists at gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki