[LLVMdev] Proposal: type uniquing of debug info for LTO

[Eric Christopher]

On Oct 1, 2013 5:57 AM, "Rafael Espíndola" <rafael.espindola at gmail.com>
wrote:
>
> On 20 June 2013 17:51, Manman Ren <mren at apple.com> wrote:
> >
> > The intent of this proposal is to speedup compilation of "-flto -g" for
c++ programs.
> > This is based on discussions with Adrian, David and Eric.
> >
> > ---------------------------
> > Problem:
> > A single class can be used in multiple source files and the DI (Debug
Info) class is included in multiple bc files. The duplication of
> > class definitions causes blow-up in # of MDNodes, # of DIEs, leading to
large memory requirement.
> >
> > As an example, SPEC xalancbmk requires 7GB of memory when compiled with
-flto -g.
> > With a preliminary implementation of type uniquing, the memory usage
will be down to 2GB.
>
> This is awesome! :-)
>
> > In order to unique types, we have to break cycles in the MDNodes.
>
> Sorry I missed this email earlier, but do we really need to break the
> cycles? This is not a generic graph isomorphism problem. If we just
> add the hashes to the metadata nodes representing types, merging then
> becomes
>
> for every two types with the same hashes:
>   try merging them recursively. The order is important, so this is
> just a dfs that succeeds or not.
>

Fwiw it's not really hashing anything, just a way to remove references and
replace it with a name that will be identical between translation units.
For C++ we can abuse the odr in places. For occasions when this isn't going
to work we can fall back to name and scope.

The idea is basically to let the folding set do all the work rather than
merge the graphs ourselves.

I gave a brief description of the problem and solution when I spoke at
eurollvm this last year.

--eric

> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131001/063dd810/attachment.html>