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

[Duncan P. N. Exon Smith]

> On 2014 Oct 16, at 22:09, Sean Silva <chisophugis at gmail.com> wrote:
> 
> Dig into this first!

This isn't the right forum for digging into ld64.

> In the OP you are talking about essentially a pure "optimization" (in the programmer-wisdom "beware of it" sense), to "save" 2GB of peak memory. But from your analysis it's not clear that this 2GB savings actually is reflected as peak memory usage saving

It's reflected in both links.

> (since the ~30GB peak might be happening elsewhere in the LTO process). It is this ~30GB peak, and not the one you originally analyzed, which your customers presumably care about.

This discussion is intentionally focused on llvm-lto.

> To recap, the analysis you performed seems to support neither of the following conclusions:
> - Peak memory usage during LTO would be improved by this plan

The analysis is based on the nodes allocated at peak memory.

> - Build time for LTO would be improved by this plan (from what you have posted, you didn't measure time at all)

CPU profiles blame 25-35% of the CPU of the ld64 LTO link on
callback-based metadata RAUW traffic, depending on the C++ program.

> Of course, this is all tangential to the discussion of e.g. a more readable/writable .ll form for debug info, or debug info compatibility. However, it seems like you jumped into this from the point of view of it being an optimization, rather than a maintainability/compatibility thing.

It's both.