<div dir="ltr">Note that this is how we do various other things like GenericDomTree.h.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 16, 2018 at 7:12 PM Zachary Turner via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 :)<br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 16, 2018 at 7:09 PM Erik Pilkington via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">erik.pilkington added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D50828#1203539" rel="noreferrer" target="_blank">https://reviews.llvm.org/D50828#1203539</a>, @rsmith wrote:<br>
<br>
> 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!<br>
<br>
<br>
+1 from me! I was just writing an argument to do something like this.<br>
<br>
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.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D50828" rel="noreferrer" target="_blank">https://reviews.llvm.org/D50828</a><br>
<br>
<br>
<br>
</blockquote></div>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>