[llvm-dev] RFC: Improving the performance of ItaniumDemangle
Vedant Kumar via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 25 12:47:29 PDT 2017
> On Apr 25, 2017, at 12:42 PM, Scott Smith <scott.smith at purestorage.com> wrote:
>
> On Tue, Apr 25, 2017 at 12:36 PM, Vedant Kumar <vsk at apple.com> wrote:
>
> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> wrote:
> >
> > well, top-of-branch lldb uses this code, that's how I found it. Do you mean libc++'s demangler?
>
> Thanks for explaining, this is the first time I'm looking at the demangler situation. It looks like libcxxabi has an arena-based demangler, and that the one in llvm is different.
>
> I'm confused by this because the comment in llvm says that libcxxabi is supposed to reuse the llvm demangler. This doesn't seem to be happening, right?
>
> I'm confused too. I'm new here :-)
>
>
> > FYI when I said 14+% (and now it's 17%), I mean the overall performance of starting lldb, not just the demangler itself. It's probably several times faster now with this change (https://reviews.llvm.org/D32500)
>
> Do you know what the llvm policy is on using TLS in library code? I can't find any mention of this in the programmer's manual, and my officemates don't know either.
>
> I don't know, and frankly I don't like using it. It was more "to get the conversation started." I can change all the string routines to take the arena as a parameter, it'll just make the diff look larger.
>
> But if libcxxapi has already done the heavy lifting then maybe I should just benchmark their demangler instead.
+ 1, with a caveat. If it turns out that the demangler in libcxxabi is faster, but that it can't be incorporated into llvm for some (unknown to me) reason, the benchmarking may be wasted effort. It would be good to ping some people who know what's up with the demanglers.
vedant
More information about the llvm-dev
mailing list