[PATCH] D50828: Add profiling and canonicalization support to demangler nodes. No functionality change intended.

[Chandler Carruth via llvm-commits]

Note that this is how we do various other things like GenericDomTree.h.

This can be arranged so that the large header is relatively isolated and
only gets pull in and instantiated in controlled ways so it doesn't explode
code size etc.

On Thu, Aug 16, 2018 at 7:12 PM Zachary Turner via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> Yea this approach is fine I guess, but I’m not really a fan of gigantic
> headers, so if it’s possible to use runtime polymorphism that seems better
> to me. Otoh, I’m not the maintainer of the itanium demangler, so feel free
> to ignore :)
> On Thu, Aug 16, 2018 at 7:09 PM Erik Pilkington via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> erik.pilkington added a comment.
>>
>> In https://reviews.llvm.org/D50828#1203539, @rsmith wrote:
>>
>> > I'm going to try to split this patch so it adds a generic visitation
>> mechanism to the demangler AST, and introduce a separate layer that
>> includes Support and builds profiling off the visitation mechanism. That
>> seems like the only way out that meets everyone's acceptance criteria.
>> However, I don't see any way to do that without moving all of the demangler
>> to a public header in include/llvm (since the whole thing will need to be
>> included from both the Demangle/ demangler and the profiling demangler).
>> That header would only be included (and the templates in it instantiated)
>> in two places in LLVM, but still, it'd be a 5000-line header file. If
>> people are strongly opposed to that approach, please shout now!
>>
>>
>> +1 from me! I was just writing an argument to do something like this.
>>
>> One more thing that I want to mention: If/when we go monorepo, then we
>> can share code between libcxxabi and llvm the old-fashioned way. Tangling
>> in support would just make it impossible to ever de-duplicate the
>> demanglers.
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D50828
>>
>>
>>
>> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180816/cbf1d238/attachment.html>