<div dir="ltr">Hi Mehdi,<div><br></div><div>I've just done an LTO build of llc with debug info:</div><div>  before: 7.66GB maximum resident set size</div><div>  after:   8.05GB (+5.1%)</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 18 Jul 2016 at 01:15 Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jul 17, 2016, at 9:34 AM, James Molloy via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> [Apologies to those receiving this mail twice - used the old list address by accident]<br>
><br>
> In LLVM it is currently not possible to write a Module-level pass (a pass that modifies or analyzes multiple MachineFunctions) after DAG formation. This inhibits some optimizations[1] and is something I'd like to see changed.<br>
><br>
> The problem is that in the backend, we emit a function at a time, from DAG formation to object emission. So no two MachineFunctions ever exist at any one time. Changing this necessarily means increasing memory usage.<br>
><br>
> I've prototyped this change and have measured peak memory usage in the worst case scenario - LTO'ing llc and clang. Without further ado:<br>
><br>
>   llvm-lto llc:   before: 1.44GB maximum resident set size<br>
>                   after:  1.68GB (+17%)<br>
><br>
>   llvm-lto clang: before: 2.48GB maximum resident set size<br>
>                   after:  3.42GB (+33%)<br>
<br>
These are non-debug build, mind you trying with debug info?<br>
<br>
Thanks,<br>
<br>
—<br>
Mehdi<br>
<br>
<br>
><br>
> The increases are very large. This is worst-case (non-LTO builds would see the peak usage of the backend masked by the peak of the midend) but still - pretty big. Thoughts? Is this completely no-go? is this something that we *just need* to do? Is crippling the backend architecture to keep memory down justified? Is this something we could enable under an option?<br>
><br>
> Any input appreciated. I can also provide a proof-of-concept patch for people to test if wanted.<br>
><br>
> Cheers,<br>
><br>
> James<br>
><br>
> [1] A concrete (and the motivating) example is the sharing of constants in constantpools across multiple functions. Two small functions that use the same constant must currently create their own copy of that constant. For many reasons that I'd not like to go into in this thread, we can't implement this *at all* in the current infrastructure.<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div>