[cfe-dev] [ClangToolsExtra] PreprocessorTrackerImpl's use of llvm::StringPool
Chris Lattner via cfe-dev
cfe-dev at lists.llvm.org
Wed Apr 15 22:29:53 PDT 2020
Cool, thanks! I put up this patch to replace this usage in favor of StringSet - once this goes in, I’ll remove StringPool entirely. I’d appreciate an LGTM, thanks!
https://reviews.llvm.org/D78273 <https://reviews.llvm.org/D78273>
-Chris
> On Apr 15, 2020, at 11:17 AM, Fangrui Song <maskray at google.com> wrote:
>
> On 2020-04-14, Reid Kleckner via cfe-dev wrote:
>> I also noticed StringPool last month and had more or less the same thought:
>> this looks dead, can we remove it?
>>
>> +1 for replacing this usage with StringSet and removing StringPool.
>
> +1. llvm/Support/StringSaver.h:UniqueStringSaver does more or less the
> same thing.
>
>> On Mon, Apr 13, 2020 at 11:03 AM Chris Lattner via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> Cc John Thompson, but I don’t know his email address.
>>>
>>> I recently ran across llvm::StringPool in llvm/lib/Support. It is an old
>>> class which isn’t ideal in several ways, and I would like to remove it in
>>> favor of direct uses of llvm::StringSet, which is nearly the same thing and
>>> a lot more efficient. The one difference is that in this one, each entry
>>> is individually reference counted, so they get deallocated as soon as the
>>> last reference is dropped.
>>>
>>> The only use of this class is in PreprocessorTrackerImpl in
>>> clang-tools-extra/modularize/PreprocessorTracker.cpp. Does anyone object
>>> to changing this to being a simple llvm::StringSet? Such a change would
>>> make this more efficient (and allow deleting a misleading class out of
>>> llvm/lib/Support), allow simplifying away the "StringHandle” logic (in
>>> favor of using StringRef directly) and the only cost that I can see is that
>>> the strings won’t get deallocated as eagerly.
>>>
>>> An alternative solution here is to move StringPool into clang-tools-extra
>>> as a private implementation detail. I’d personally rather remove it
>>> outright than preserve it.
>>>
>>> Any thoughts?
>>>
>>> -Chris
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200415/a049584c/attachment.html>
More information about the cfe-dev
mailing list