<div dir="ltr"><div dir="ltr">On Wed, Sep 4, 2019 at 2:17 PM David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Probably the simple thing that might help would be to split up the file a bit - especially the functions that include PassRegistry.def as part of their implementation. I'm guessing the parse.*Pass functions are the worst parts and having each of those in a separate file is probably helpful.<br></div></blockquote><div><br></div><div>This may not help as much as you'd like. I suspect they're all going to instantiate a similar set of templates, so you may end up with N expensive files instead of 1.</div><div><br></div><div>=/</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Other than that - actually changing the constructs to use less memory overall, I'm not sure. </div></blockquote><div><br></div><div>Things that would likely help a lot here:</div><div><br></div><div>1) Looking at the templates in PassManager.h that get instantiated per-pass and have nested types or other constructs and refactoring them so that they don't.</div><div>2) Looking at some of the especially large headers and refactoring them so that we don't need to include them. AliasAnalysis.h and ScalarEvolution.h would be my first targets, but that's just based on intuition, not profiling.</div><div><br></div><div>I suspect there is a decent amount of improvement available for both #1 and #2.</div><div><br></div><div>The other thing that might help would be splitting apart the parsing code from the fixed pipeline building code -- those actually use somewhat different bits of pass management infrastructure and so we might get a win from separating their compilation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 3, 2019 at 7:12 PM Stefan Pintilie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font size="2" face="sans-serif">Hi Everyone,<br><br>Recently I have realised that compiling the file PassBuilder.cpp takes
a significant amount of memory. I have seen anywhere between 700 MB to
over 1GB depending on which build compiler is used. This memory consumption
recently caused a couple of build bots that run on a smaller machine to
run out of memory and fail to build.<br></font><br><font size="2" face="sans-serif">I have no intention of changing any
of the functionality of this file but I was wondering if anyone could suggest
a way to reduce its complexity (and hopefully memory consumption).</font><br><font size="2" face="sans-serif">Any ideas of how I could try to go about
this? Would it be possible to refactor parts into another file perhaps?</font><br><br><font size="2" face="sans-serif">Thank you in advance,</font><br><font size="2" face="sans-serif">Stefan</font><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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>