search for: 8951a345

...d their members. This avoids the raw bitcode >> reading overhead. (This is totally undesigned at this point.) >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/8951a345/attachment.html>

+pcc, who had some other ideas/patch out for improving memory usage of debug info +Reid, who's responsible for the windows/CodeView/PDB debug info which is motivating some of the ideas about changes to type emission So how does this relate, or not, to Peter's (pcc) work trying to reduce the DIE overhead during code gen? Are you folks chasing different memory bottlenecks? Are they both

I have some ideas to allow the BitcodeReader to lazy-load debug info metadata, and wanted to air this on llvm-dev before getting too deep into the code. Motivation ========== Based on some analysis Mehdi ran (ping him for details), there are three (related) compile-time bottlenecks we're seeing with `-flto=thin -g`: a) Reading the large number of Metadata bitcode records in the global