<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 4/25/17 2:37 PM, Asiri Rathnayake
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAGhzUqK-9MQsVjwnsUSE78nocGyj+hy_yGBb6bo8wMd2zbRabA@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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
                moz-do-not-send="true"
                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
                  moz-do-not-send="true"
                  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>
        </div>
      </div>
    </blockquote>
    <br>
    A copy of the libcxxabi one was added to libSupport relatively
    recently so that lldb could use it.... so they should be almost the
    same.<br>
    <br>
    lldb has its own because it has different constraints w.r.t. memory
    allocation and speed compared to the __cxa_* one. (I don't know much
    about the details there though). If falls back on the __cxa_*
    implementation for some cases where the "fast" one's implementation
    is incomplete (again, repeating what I remember... I don't know the
    details).<br>
    <br>
    <br>
    Jon<br>
    <blockquote
cite="mid:CAGhzUqK-9MQsVjwnsUSE78nocGyj+hy_yGBb6bo8wMd2zbRabA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <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 moz-do-not-send="true"
                  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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
                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 moz-do-not-send="true"
                    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 moz-do-not-send="true"
                    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 moz-do-not-send="true"
                    href="mailto:llvm-dev@lists.llvm.org"
                    target="_blank">llvm-dev@lists.llvm.org</a><br>
                  > > <a moz-do-not-send="true"
                    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 moz-do-not-send="true"
                    href="mailto:llvm-dev@lists.llvm.org"
                    target="_blank">llvm-dev@lists.llvm.org</a><br>
                  <a moz-do-not-send="true"
                    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>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Jon Roelofs
<a class="moz-txt-link-abbreviated" href="mailto:jonathan@codesourcery.com">jonathan@codesourcery.com</a>
CodeSourcery / Mentor Embedded / Siemens</pre>
  </body>
</html>