(original) (raw)

On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev <llvm-dev@lists.llvm.org> wrote:

\> On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith@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?

This seems correct. libcxxabi demangler \[1\] is different from the one used by llvm \[2\]. I'm hoping Saleem, Eric or Jon (copied) knows a bit of history as to why this is so (perhaps because the two projects evolved independently ?).

\> 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.

Both libcxx and libcxxabi use \_\_libcpp\_tls\_\*() functions of the threading API \[2\] (which call pthread functions on most platforms) for thread-local storage needs. IIRC thread\_local is not implemented across all the platforms that llvm support.

If the idea is to improve libcxxabi's demangler, then it should be straightforward to use these functions instead of thread\_local.

\[1\] https://github.com/llvm-mirror/libcxxabi/blob/master/src/cxa\_demangle.cpp

\[2\] https://github.com/llvm-mirror/llvm/blob/master/lib/Demangle/ItaniumDemangle.cpp

\[3\] https://github.com/llvm-mirror/libcxx/blob/master/include/\_\_threading\_support

PS: Here's a particularly amusing bug of the current libcxxabi demangler: https://bugs.llvm.org//show\_bug.cgi?id=31031

Cheers,

/ Asiri

vedant

\> On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk@apple.com> wrote:
\> I thought the plan of record was (r280732):
\>
\> '''
\> Once the fast demangler in lldb can handle any names this
\> implementation can be replaced with it and we will have the one true
\> demangler.
\> '''
\>
\> What is the status of lldb's fast demangler? Is it available on Ubuntu 16.04?
\>
\> vedant
\>
\>
\> > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev <llvm-dev@lists.llvm.org> wrote:
\> >
\> > (Again), while trying to improve the performance of lldb, I ran into a bottleneck with the demangler. This may be specific to my platform - Ubuntu 16.04, probably using libstdc++, not libc++. It makes extensive use of std::string and std::vector, and I see memory allocation at the top. I prototyped a version that uses an arena-style memory allocator (you can allocate, but you can't ever free). It is approximately 14+% faster. I think I can further optimize it by making repeated appends zero-copy (for the string being appended too).
\> >
\> > The code right now is a little ugly, because it uses a thread local variable to pass around the arena pointer, rather than change every + and += to be function calls that take db.arena as a parameter. I'm not sure what you guys would prefer for that either (thread local variable vs api change).
\> >
\> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> > LLVM Developers mailing list
\> > llvm-dev@lists.llvm.org
\> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
\>
\>

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
LLVM Developers mailing list
llvm-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev