search for: mdnodeoperand

...my numbers come from. I got the 15.3GB from a profile of memory usage vs. time. Peak usage comes late in the process, around when DIEs are being dealt with. Metadata node counts stabilize much earlier in the process. The rest of the numbers are based on counting `MDNodes` and their respective `MDNodeOperands`, and multiplying by the cost of their operands. Here's a dump from around the peak metadata node count: LineTables = 7500000[30000000], InlinedLineTables = 6756182, Directives = 7611669[42389128], Arrays = 570609[577447], Others = 1176556[5133065] Tag = 256, Count = 554992, Ops...

...relationship between `MDNode` and `MDUser`/ `CustomMD`. Both `User` and `MDNode` implement support for an arbitrary number of operands, but using completely incompatible mechanisms. Since `MDNode` can reference an arbitrary number of arbitrary `Value`s, it uses a subclass of `CallbackVH` called `MDNodeOperand` that costs 32B (x86-64). Moreover, RAUW is expensive. `MDUser`/`CustomMD` inherits from `User` so that its subclasses can leverage the use-list infrastructure (8B per operand, fast RAUW). > I also have to ask because I can't currently see it: what does debug info being metadata buy us?...

In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan,

I've attached a preliminary patch for `MDLocation` as a follow-up to the RFC [1] last week. It's not commit-ready -- in particular, it squashes a bunch of commits together and doesn't pass `make check` -- but I think it's close enough to indicate the direction and work toward consensus. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html IMO, the files to