<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 25, 2017 at 1:51 PM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class=""></span>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></div></blockquote><div><br></div><div>I didn't realize lldb had its own demangler.  It must not be very thorough, because my lldb session was falling back to llvm's demangler quite a lot!<br><br></div><div>Without my change, disabling lldb's FastDemangler is ~10% slower.<br></div><div>With my change, disabling lldb's FastDemangler is ~1.25% slower.<br></div><div class="m_7584861971798062931gmail-m_-4215032370368620547gmail-h5">(as measured by perf stat running lldb, # of cycles.  Interesting, the instruction count difference is much larger, implying lldb's demangler has very poor IPC).<br><br></div></div></div></div>