<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 6:04 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> On Oct 17, 2014, at 3:54 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br>
><br>
> this seems like the classic situation where the someone comes to you asking for X, but what they really want is a solution to underlying problem Y, for which the best solution, once you actually analyze Y, is Z.<br>
<br>
</span>On the contrary, I came into this expecting to work with Eric on<br>
parallelizing the backend, but consistently found that callback-based<br>
RAUW traffic for metadata took almost as much CPU.<br></blockquote><div><br></div><div>Derp. My bad. It would be nice in the future if you communicated this better in the OP. In the OP it sounds like you are doing this solely for memory, since there is no mention of CPU time or the excessive callback-based RAUW traffic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Since debug info IR is at the heart of the RAUW bottleneck, I looked<br>
into its memory layout (it's a hog).  I started working on PR17891<br>
because, besides improving the memory usage, the plan promised to<br>
greatly reduce the number of nodes (indirectly reducing RAUW traffic).<br>
<br>
In the context of `llvm-lto`, "stage 1" knocked memory usage down from<br>
~5GB to ~3GB -- but didn't reduce the number of nodes.</blockquote><div><br></div><div>Please put these numbers in context. In the OP you were talking about 15.3GB peak for llvm-lto. Why is ~5GB now the peak? Also in the OP, the theoretical improvement, out of 15.3GB, was 2GB after stage 4. How are you getting 2GB improvement out of ~5GB with only stage 1?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Before starting<br>
stages "2" and "3", I counted nodes and operands to find which to tackle<br>
first.  Unfortunately, our need to reference local variables and line<br>
table entries directly from the IR-proper limits our ability to refactor<br>
the schema, and those are the nodes we have the most of.<br>
<br>
This work will drop debug info memory usage in `llvm-lto` further, from<br>
~3GB down to ~1GB.  It's also a big step toward improving debug info<br>
maintainability.<br>
<br>
More importantly (for me), it enables us to refactor uniquing models and<br>
reorder serialization and linking to design away debug info RAUW<br>
traffic -- assuming switching to use-lists doesn't drop it off the<br>
profile.<br>
<br>
Regarding "the bigger problem" of LTO memory usage, I expect to see more<br>
than a 2GB drop from this work due to the nature of metadata uniquing<br>
and expiration.  I'm not motivated to quantify it, since even a 2GB drop<br>
-- when combined with a first-class IR and the RAUW-related speedup --<br>
is motivation enough.<br>
<br>
There's a lot of work left to do in LTO -- once I've finished this, I<br>
plan to look for another bottleneck.  Not sure if I'll tackle memory<br>
usage or performance.<br>
<br>
As Bob suggested, please feel free to join the party!  Less work for me<br>
to do later.<br></blockquote><div><br></div><div>I'm planning on it.</div><div><br></div><div>-- Sean Silva </div></div><br></div></div>