llvm dev - Jun 2017 - RFC: Cleaning up the Itanium demangler

On 6/22/17 7:50 AM, Joerg Sonnenberger via llvm-dev
wrote:
> On Wed, Jun 21, 2017 at 04:42:40PM -0700, Erik Pilkington via llvm-dev
wrote:
>> 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.
> How does it far in terms of code size? One of the big problems with the
> libcxxabi demangler is its size. It's at least twice as large as the
one
> in elftoolchain, even ignoring some possible feature differences.
Looks pretty good, I'm guessing this is because all the string 
operations aren't getting inlined into the parser anymore.
Before this patch:
__TEXT    __DATA  __OBJC    others  dec       hex
247293    0       0         1248    248541    3cadd 
libc++abi.a(cxa_demangle.cpp.o)

After this patch:
__TEXT    __DATA  __OBJC    others  dec       hex
137723    4216    0         6016    147955    241f3 
libc++abi.a(cxa_demangle.cpp.o)
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Thu, Jun 22, 2017 at 08:34:02AM -0700, Erik Pilkington
wrote:
> 
> 
> On 6/22/17 7:50 AM, Joerg Sonnenberger via llvm-dev wrote:
> > On Wed, Jun 21, 2017 at 04:42:40PM -0700, Erik Pilkington via llvm-dev
wrote:
> > > 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.
> > How does it far in terms of code size? One of the big problems with
the
> > libcxxabi demangler is its size. It's at least twice as large as
the one
> > in elftoolchain, even ignoring some possible feature differences.
> Looks pretty good, I'm guessing this is because all the string
operations
> aren't getting inlined into the parser anymore.
> Before this patch:
> __TEXT    __DATA  __OBJC    others  dec       hex
> 247293    0       0         1248    248541    3cadd
> libc++abi.a(cxa_demangle.cpp.o)
> 
> After this patch:
> __TEXT    __DATA  __OBJC    others  dec       hex
> 137723    4216    0         6016    147955    241f3
> libc++abi.a(cxa_demangle.cpp.o)
Better, but still huge compared to:

   text    data     bss     dec     hex filename
  44560       0       0   44560    ae10 rt_libelftc_dem_gnu3.pico

Joerg

One thing I'd noticed in the past is that the existing libcxxabi
cxa_demangle.o code is *MUCH* smaller when compiled by GCC, vs the same
code compiled by clang.

On ARM, it was approximately 40K (gcc -Os), 50K (gcc -O2), 70K (clang -Os),
115K (clang -O2) of TEXT.

I didn't investigate any further, but that seemed somewhat striking.


On Thu, Jun 22, 2017 at 11:47 AM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, Jun 22, 2017 at 08:34:02AM -0700, Erik Pilkington wrote:
> >
> >
> > On 6/22/17 7:50 AM, Joerg Sonnenberger via llvm-dev wrote:
> > > On Wed, Jun 21, 2017 at 04:42:40PM -0700, Erik Pilkington via
llvm-dev
> wrote:
> > > > 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.
> > > How does it far in terms of code size? One of the big problems
with the
> > > libcxxabi demangler is its size. It's at least twice as large
as the
> one
> > > in elftoolchain, even ignoring some possible feature differences.
> > Looks pretty good, I'm guessing this is because all the string
operations
> > aren't getting inlined into the parser anymore.
> > Before this patch:
> > __TEXT    __DATA  __OBJC    others  dec       hex
> > 247293    0       0         1248    248541    3cadd
> > libc++abi.a(cxa_demangle.cpp.o)
> >
> > After this patch:
> > __TEXT    __DATA  __OBJC    others  dec       hex
> > 137723    4216    0         6016    147955    241f3
> > libc++abi.a(cxa_demangle.cpp.o)
>
> Better, but still huge compared to:
>
>    text    data     bss     dec     hex filename
>   44560       0       0   44560    ae10 rt_libelftc_dem_gnu3.pico
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170622/6df91ee5/attachment.html>