[PATCH] [PATCH/RFC] Use a BumpAllocator for DIEs
dblaikie at gmail.com
Tue Jan 27 16:11:05 PST 2015
On Tue, Jan 27, 2015 at 2:08 PM, Frederic Riss <friss at apple.com> wrote:
> This update removes the limitation to a fixed maximum number of
> attributes per DIE. The patch is very similar to the first one that
> I sent for discussion. It only adds a pointer to a vector of DIEs
> as arguement to DIE::addValue(). If a DIE overflows its inline storage
> for attributes, it is added to the vector. The vector is then iterated
> just before the BumpPtrAllocator is destroyed to call the destructors
> of all these DIEs.
> This approach gives the most flexibilty as it doesn't impose the
> memory management upon the user (for example DIEHashTest.cpp continues
> to use stack allocated DIEs and it works fine).
> I've been playing with this for the last few days, and I have quite
> a few different implementations lying around (for example using
> std::vectors with a custom stateful allocator). They are all more
> complicated and don't perform as well as this patch.
> There's one point that I'd like to mention: the patch unifies the
> existing bookkeeping of the DIEBlock and DIELoc objects and treats
> them the same as standard DIEs. This means that we will call ~DIE
> on DIEBlock and DIELoc objects which will result in a 'partial'
> destruction (DIEBlock inherits both from DIEValue and from DIE).
> I think this is fine. It should do exactly what we want and just
> call the destructors of the SmallVectors in the DIE part of the
> object, but I wanted to mention it in case someone thinks its not
> legal to do that.
Pretty sure that's not valid C++ (not sure quite which cracks the bump
allocator objects fall in general in terms of not running dtors, reusing
memory, etc - and whether this would be worse than that or not, though).
> EMAIL PREFERENCES
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits