[PATCH] Make StringMap aware of POD types

Pete Cooper peter_cooper at apple.com
Mon Mar 17 12:39:15 PDT 2014


On Mar 17, 2014, at 12:36 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Mon, Mar 17, 2014 at 12:27 PM, Benjamin Kramer <benny.kra at gmail.com> wrote:
> On 17.03.2014, at 20:10, Pete Cooper <peter_cooper at apple.com> wrote:
> 
> >
> > On Mar 17, 2014, at 11:57 AM, Benjamin Kramer <benny.kra at gmail.com> wrote:
> >
> >>
> >> On 17.03.2014, at 19:47, Pete Cooper <peter_cooper at apple.com> wrote:
> >>
> >>> Hi all
> >>>
> >>> Please review this patch to make StringMap be aware of when it contains POD types allocated on a BumpPtrAllocator.  In this case its unnecessary to clear the map in its destructor.  This is particularly painful on IdentiferTable in clang where we walk an 8192 entry map of pointers and uselessly destruct them.
> >>
> >> Ugh. This is really something that the optimizer should do. Have you checked
> >> what's preventing LLVM from killing the loop that does nothing?
> > I think it’ll do the right thing in terms of the destructors for each element being empty.  The tricky thing is that unless ~StringMap inlines clear(), the resetting of all of the elements to the tombstone key will also still happen, and on a large map that can be really slow.
> 
> In that case, why not just copy the loop into the dtor and remove the zeroing there. Thats only a small amount of duplication and should have the same effect as your isPODLike contraption.
> 
> I strongly prefer this approach to more POD-like hackery here.
Just as an aside, why have isPodLike if not to enable POD-like hackery?  Seems like thats all its useful for?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140317/27bdc7ff/attachment.html>


More information about the llvm-commits mailing list