[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Oct 14 13:17:08 PDT 2014

>> Stupid question, but when I was working on LTO last Summer the primary
>> culprit for excessive memory use was due to us not being smart when linking
>> the IR together (Espindola would know more details). Do we still have that
>> problem? For starters, how does the memory usage of just llvm-link compare
>> to the memory usage of the actual LTO run? If the issue I was seeing last
>> Summer is still there, you should see that the invocation of llvm-link is
>> actually the most memory-intensive part of the LTO step, by far.
> This is vague. Could you be more specific on where you saw all of the memory?

I think Sean is referring to the old problem of nodes not being merged
because of cycles. It has been fixed by breaking the cycles by having
some of the edges be represented with stable mangled names.

The problem that Duncan is trying to solve is that the debug info is
still very large, even with the duplicate information removed.


More information about the llvm-dev mailing list