<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-4215032370368620547gmail-"><br>
> On Apr 25, 2017, at 12:24 PM, Scott Smith <<a href="mailto:scott.smith@purestorage.com" target="_blank">scott.smith@purestorage.com</a>> wrote:<br>
><br>
> well, top-of-branch lldb uses this code, that's how I found it. Do you mean libc++'s demangler?<br>
<br>
</span>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.<br>
<br>
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?<br></blockquote><div><br></div><div>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 ?).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-4215032370368620547gmail-"><br>
<br>
> 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 (<a href="https://reviews.llvm.org/D32500" rel="noreferrer" target="_blank">https://reviews.llvm.org/D325<wbr>00</a>)<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>If the idea is to improve libcxxabi's demangler, then it should be straightforward to use these functions instead of thread_local.</div><div><br></div><div>[1] <a href="https://github.com/llvm-mirror/libcxxabi/blob/master/src/cxa_demangle.cpp" target="_blank">https://github.com/llvm-<wbr>mirror/libcxxabi/blob/master/<wbr>src/cxa_demangle.cpp</a></div><div>[2] <a href="https://github.com/llvm-mirror/llvm/blob/master/lib/Demangle/ItaniumDemangle.cpp">https://github.com/llvm-mirror/llvm/blob/master/lib/Demangle/ItaniumDemangle.cpp</a></div><div>[3] <a href="https://github.com/llvm-mirror/libcxx/blob/master/include/__threading_support" target="_blank">https://github.com/llvm-<wbr>mirror/libcxx/blob/master/<wbr>include/__threading_support</a><br></div><div><br></div><div>PS: Here's a particularly amusing bug of the current libcxxabi demangler: <a href="https://bugs.llvm.org//show_bug.cgi?id=31031">https://bugs.llvm.org//show_bug.cgi?id=31031</a></div><div><br></div><div>Cheers,</div><div><br></div><div>/ Asiri</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
vedant<br>
<div class="gmail-m_-4215032370368620547gmail-HOEnZb"><div class="gmail-m_-4215032370368620547gmail-h5"><br>
<br>
> On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <<a href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>> wrote:<br>
> I thought the plan of record was (r280732):<br>
><br>
> '''<br>
> Once the fast demangler in lldb can handle any names this<br>
> implementation can be replaced with it and we will have the one true<br>
> demangler.<br>
> '''<br>
><br>
> What is the status of lldb's fast demangler? Is it available on Ubuntu 16.04?<br>
><br>
> vedant<br>
><br>
><br>
> > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > (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).<br>
> ><br>
> > 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).<br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>