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

Chandler Carruth via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 16 18:17:41 PDT 2018


chandlerc added a comment.

In https://reviews.llvm.org/D50828#1203532, @erik.pilkington wrote:

> In https://reviews.llvm.org/D50828#1203493, @zturner wrote:
>
> > Another option is to simply move it into support and say that going forward
> >  merges to libcxxabi might get more difficult. Perhaps this isn’t so bad
> >  though. Isn’t the itanium demangler mostly complete? If the potential for
> >  future changes to it is low, maybe this is an acceptable tradeoff.
>
>
> It's pretty much complete, but there is still going to be a steady stream of updates. Each release of C++ is likely to add a handful more constructs that need manglings, and often new attributes/extensions get custom manglings that need to be handled as well.
>
> > Then we
> >  could just move it to support, use it and evolve it any way we want with no
> >  restrictions, and when new functionality gets added to the itanium mangler
> >  that needs to be port to libcxxabi, it’s a little more effort than a simple
> >  copy paste because you have to think about it some.
> > 
> > Thoughts?
>
> -1 from me, large-scale refactorings such as this, or Pavel's plans here: https://reviews.llvm.org/D50599 would make updating/fixing bugs in the demangler a nightmare. I really don't want to have to implement every feature twice. Not to mention its just plain ugly to have two vaguely similar demanglers in the source tree.


This, combined with the comments on the move of the library IMO make it very clear what our two realistic choices are.

We can either make Demangle part of Support, and if we do so I think Zach is essentially right about how we do this (it'll move, the directory structure and other things will change), or we don't.

If we don't, we can't (even conditionally) use Support.

So the choices become:
a) We truly merge this into Support (and force manual porting of bugfixes between the two versions) and get all of the interesting enhancements we're talking about here such as what Richard is working on.
b) We don't merge this into Support, we keep it truly separate as it is today, and we do the very significant refactorings necessary to support these kinds of facilities with the layering as it is.

I'm worried that (b) will turn into "we don't get the fancy features at all" which worries me. But I'm seeing very little good compromise between (a) and (b). =/


Repository:
  rL LLVM

https://reviews.llvm.org/D50828





More information about the llvm-commits mailing list