[PATCH] Make StringMap aware of POD types

[Pete Cooper]

On 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 was worried about duplication, but actually that might be cleaner.  I’ll give that a try now.

Thanks,
Pete
> 
>>>> Unfortunately I needed to move a couple of class declarations inside their headers instead of cpp files (to use isPODLike), but otherwise I hope this looks ok.  I’m totally open to suggestions on better naming or a better way to enable this functionality.
>>>> 
>>>> There’s also a small clang diff.  I’ll didn’t want to cross-post both lists so will wait until the other details are worked out before I email it there.
>>> 
>>> If I'm reading the source correctly, clang::tooling::FileMatchTrieNode contains a
>>> std::string. That's very non-POD-like.
>> Yeah, thats a nasty piece of code.  I was hoping someone with more C++ template knowledge might know what i’m doing wrong in having to declare this.
>> 
>> Without that declaration, I get these errors
>> 
>> In file included from /Volumes/Data/llvm/tools/clang/lib/Tooling/FileMatchTrie.cpp:14:
>> In file included from /Volumes/Data/llvm/tools/clang/lib/Tooling/../../include/clang/Tooling/FileMatchTrie.h:18:
>> In file included from /Volumes/Data/llvm/tools/clang/lib/Tooling/../../include/clang/Basic/LLVM.h:22:
>> In file included from /Volumes/Data/llvm/include/llvm/Support/Casting.h:19:
>> /Volumes/Data/llvm/include/llvm/Support/type_traits.h:34:29: error: incomplete type
>>      'clang::tooling::FileMatchTrieNode' used in type trait expression
>>  static const bool value = __is_trivially_copyable(T);
>>                            ^
>> /Volumes/Data/llvm/include/llvm/ADT/StringMap.h:253:29: note: in instantiation of template class
>>      'llvm::isPodLike<clang::tooling::FileMatchTrieNode>' requested here
>>    public StringMapClearer<isPodLike<ValueTy>::value, AllocatorTy> {
>>                            ^
>> /Volumes/Data/llvm/tools/clang/lib/Tooling/FileMatchTrie.cpp:136:21: note: in instantiation of template
>>      class 'llvm::StringMap<clang::tooling::FileMatchTrieNode, llvm::MallocAllocator>' requested here
>>              llvm::StringMap<FileMatchTrieNode>::const_iterator Except) const {
>>                    ^
>> /Volumes/Data/llvm/tools/clang/lib/Tooling/FileMatchTrie.cpp:36:7: note: definition of
>>      'clang::tooling::FileMatchTrieNode' is not complete until the closing '}'
>> class FileMatchTrieNode {
> 
> I see. I guess we could add some template magic so isPodLike works on incomplete types. Maybe we don't need it.
> 
> - Ben

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