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

<p dir="ltr">The idea is basically to let the folding set do all the work rather than merge the graphs ourselves.</p>
<p dir="ltr">I gave a brief description of the problem and solution when I spoke at eurollvm this last year. </p>
<p dir="ltr">--eric</p>
<p dir="ltr">> Cheers,<br>
> Rafael<br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</p>