[llvm-dev] RFC: Cleaning up the Itanium demangler

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 21 17:23:20 PDT 2017


Hi Erik,

Thanks for working on this!

2017-06-21 16:42 GMT-07:00 Erik Pilkington via llvm-dev <
llvm-dev at lists.llvm.org>:

> Hello all,
> The itanium demangler in libcxxabi (and also, llvm/lib/Demangle) is really
> slow. This is largely because the textual representation of the symbol that
> is being demangled is held in a std::string, and manipulations done during
> parsing are done on that string. The demangler is always concatenating
> strings and inserting into the middle of strings, which is terrible. The
> fact that the parsing logic and the string manipulation/formatting logic is
> interleaved also makes the demangler pretty ugly. Another problem was that
> the demangler used a lot stack space, and has a bunch of stack overflows
> filed against it.
>
> I've been working on fixing this by parsing first into an AST structure,
> and then traversing that AST to produce a demangled string. This provides a
> significant performance improvement and also make the demangler somewhat
> more clean. Attached you should find a patch to this effect. This patch is
> still very much a work in progress, but currently passes the libcxxabi test
> suite and demangles all the symbols in LLVM identically to the current
> demangler. It also provides a significant performance improvement: it
> demangles the symbols in LLVM about 3.7 times faster than the current
> demangler. Also, separating the formatting code from the parser reduces
> stack usage (the activation frame for parse_type reduced from 416 to 144
> bytes on my machine). The stack usage is still pretty bad, but this helps
> with some of it.
>
> Does anyone have any early feedback on the patch? Does this seem like a
> good direction for the demangler?
>

+David Majnemer who had some opinion about the direction.



>
> As far as future plans for this file, I have a few more refactorings and
> performance improvements that I'd like to get through. After that, it might
> be interesting to try to replace the FastDemangle.cpp demangler in LLDB
> with this, to restore the one true demangler in the source tree. The
> FastDemangler.cpp is only partially completed, and calls out to
> ItaniumDemangle.cpp in llvm (which is a copy of cxa_demangle.cpp) if it
> fails to parse the symbol.
>
> Any thoughts here would be appreciated!


I've been frustrated by how terrible the existing libcxxabi demangler was
written and documented. I'd really like to see the new one up to the usual
LLVM standard in terms of coding style, quality of implementation, and
documentation of the code.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170621/47a211cd/attachment.html>


More information about the llvm-dev mailing list