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

[Manman Ren]

On Tue, Oct 1, 2013 at 5:54 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.
>

We considered the approach you mentioned above, to implement that, we need
to have special handling for debug info MDNodes.

For example:
a special implementation of the profiling function to make two types with
the same hash have the same profiling.
special handling at linking time to merge the type nodes.

We chose to localize the changes to debug info itself by using the hash
(type identifier: the current notation) when referring to a type node.

Thanks,
Manman


>
> 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/baab8d13/attachment.html>