[PATCH] [PATCH/RFC] Use a BumpAllocator for DIEs

[David Blaikie]

Yeah, I'm punting on the language lawyering to Richard, hopefully...

On Thu, Feb 5, 2015 at 9:25 AM, Frédéric Riss <friss at apple.com> wrote:

> ping?
>
> On Jan 27, 2015, at 6:43 PM, Frédéric Riss <friss at apple.com> wrote:
>
>
> On Jan 27, 2015, at 4:11 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> 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).
>
>
> What exactly do you think the issue would be from a language standpoint?
> Calling a destructor on a ‘partial’ object? I would expect that it is ok to
> do so. AFAIK, explicit destructor calls follow the same rules as other
> function calls. I have a pointer to a DIE object, thus I can call the
> destructor on it. The object stops to ‘exist’ at that point, and thus its
> enclosing object is in an undefined state, but this doesn’t really matter
> as it won’t be touched anymore.
>
> I’m very bad at language lawyering though, thus I’d really appreciate a
> authoritative answer :-)
>
> Fred
>
>
>>
>> http://reviews.llvm.org/D7072
>>
>> Files:
>>   include/llvm/CodeGen/DIE.h
>>   lib/CodeGen/AsmPrinter/DIE.cpp
>>   lib/CodeGen/AsmPrinter/DIEHash.cpp
>>   lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
>>   lib/CodeGen/AsmPrinter/DwarfCompileUnit.h
>>   lib/CodeGen/AsmPrinter/DwarfDebug.cpp
>>   lib/CodeGen/AsmPrinter/DwarfFile.cpp
>>   lib/CodeGen/AsmPrinter/DwarfUnit.cpp
>>   lib/CodeGen/AsmPrinter/DwarfUnit.h
>>   unittests/CodeGen/DIEHashTest.cpp
>>
>> EMAIL PREFERENCES
>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150206/e44a988d/attachment.html>