On 30.09.2013, at 19:45, Marshall Clow <[email protected]> wrote:
> On Sep 25, 2013, at 2:21 PM, Chandler Carruth <[email protected]> wrote: > >> I also know that regardless of the solution, Marshall has thoughts on the >> best way to factor this within the library, but those are orthogonal. > > Benjamin -- > > Here's my suggestion. > > No matter how this comes out, I think having one place in the library where > we allocate memory "in a default" manner is a good thing. > So let's do that first. > > My suggestion is > > 1) Define two routines (probably in <new>): > > _LIBCPP_ALWAYS_INLINE void *__allocate ( std::size_t sz ) { return > ::operator new ( sz ); } > _LIBCPP_ALWAYS_INLINE void *__deallocate ( void * p ) { return > ::operator delete ( p ); } > > [ MIght need different names, since hash_table has a __deallocate and > dynarray has an __allocate and __deallocate ] > > and call them from the places in <memory> that you noted. > > 2) Make sure that works, then switch them (__allocate/__deallocate) to use > new char []/delete [] and make sure that your optimization still works. > Then, switch them back while we figure out the correct way to solve this. > > 3) Next, find all the places in libc++ where we call ::operator new/delete, > and switch them over to calling __allocate/__deallocate. > That way, when we figure out the best way to solve this, we'll reap the > benefits library-wide. > > How does that sound to you? It sounds like a great first step! Howard probably has an opinion on where's the best place for the new functions. - Ben _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
