<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Drive-by thought, debug-info-for-profiling retains source info, maybe that could be unconditionally on and Rpass could use it?<o:p></o:p></p>
<p class="MsoNormal">--paulr<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>David Blaikie via cfe-dev<br>
<b>Sent:</b> Monday, September 20, 2021 8:19 PM<br>
<b>To:</b> Arthur Eubanks <aeubanks@google.com><br>
<b>Cc:</b> Clang Dev <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Clearing Clang AST before running backend optimizations/codegen to save memory<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Sep 20, 2021 at 3:04 PM Arthur Eubanks <<a href="mailto:aeubanks@google.com">aeubanks@google.com</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Looking at -Rpass (and various things like warnings for inability to vectorize when we specifically request it with #pragma clang loop vectorize(enable)), it does end up using objects from the AST to approximate the source location (BackendConsumer::getBestLocationFromDebugLoc())
if it can't find the source location from debug info. So this would affect users who don't build with debug info. Without debug info or the AST, clang will print a warning/remark without a source location. This is a tradeoff we'd have to decide on.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ah, the AST lookup is only to retrieve the location of a function by name - if we made a mapping/record of all those locations (shouldn't take up much space, I'd think) then we could use that instead and not need the AST for that callback?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">There's a similar issue with backend warnings but those don't even pass debug info to the diagnostic handler (clang/test/Misc/backend-stack-frame-diagnostics.cpp). Perhaps it could be extended to do that though.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I haven't looked too much into the -disable-free stuff, but the reason it mitigates crashes is because if we clear AST objects we still have dangling references to them that we later attempt to clean up unless we -disable-free.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So disabling free is keeping more things alive - perhaps then the RAM savings aren't as much as they could be if freeing was enabled? But yeah, more to look into.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Updated <a href="https://urldefense.com/v3/__https:/reviews.llvm.org/D109781__;!!JmoZiZGBv3RvKRSx!u5xov9_zHGWKWsFWg-FlBBUrKZWcBw4KyfXq4eY9dQRAIJUNxoTfDwD40IYGep3Mdg$" target="_blank">
https://reviews.llvm.org/D109781</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Sep 17, 2021 at 4:41 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">I think it'd be unfortunate if certain features don't work in this mode, unless we understand why/are pretty sure that's a fairly fundamental limitation. For instance, at Google we've got memory limitations (hence the motivation for this
work) and I think we created, or at least have some interest in -Rpass - if -Rpass couldn't be composed with this feature, then we'd make it harder to investigate performance issues (because -Rpass wouldn't be available) in larger compiles that need this memory
savings to fit into the memory limits we have. I'd guess the issue is that -Rpass I think traffics in Clang source locations. So it's possible the source location infrastructure/data structures would have to be kept, even though the AST/semantic pieces could
be torn down. (unless that source location stuff can refer into ASTs for differentiating template specializations, etc - that'd be the tipping point for me in "OK, it may be worth the benefit to make these incompatible, or reduce the quality of -Rpass diagnostics
when using this memory saving technique" - wonder if it's only the -Rpass diagnostics, or other backend diagnostics that use that infrastructure)<br>
<br>
Which is to say I'd be /slightly/ averse to adding this feature as a Clang default or driver flag (& similarly averse to leaving it as a cc1 off-by-default flag indefinitely) without a pretty good answer to those crashing/non-functioning tests.<br>
<br>
(lower priority, but fairly nice-to-have would be some answer to the cleaning up issues, -disable-free, etc - sort of weird that we'd have to /disable-free/ to enable freeing things earlier... that seems pretty suspicious)<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">but if those issues can be resolved<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Sep 17, 2021 at 2:30 PM Arthur Eubanks via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">We keep around the Clang AST when we do backend optimizations on the IR. This causes the peak memory usage to be more than necessary since (I believe) generally we don't need the Clang AST when running optimizations. This gives us more
room to work with things like caching analyses, at least for frontend compilations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Measuring the effects of this when building LLVM's PassBuilder.cpp (longest LLVM file to compile), I measured a drop of peak memory usage (/usr/bin/time's max rss) from ~1.3-1.4G to ~1.0G.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There are still a couple issues I haven't dug too deeply into yet, mostly to do with cleaning things up when freeing memory, so right now it's only enabled with -disable-free which works around those issues. Most clang tests pass with this
patch; there are a couple things that crash (e.g. -Rpass, clang interpreter) where we can investigate further or just disable this feature.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Prototype: <a href="https://urldefense.com/v3/__https:/reviews.llvm.org/D109781__;!!JmoZiZGBv3RvKRSx!u5xov9_zHGWKWsFWg-FlBBUrKZWcBw4KyfXq4eY9dQRAIJUNxoTfDwD40IYGep3Mdg$" target="_blank">
https://reviews.llvm.org/D109781</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://urldefense.com/v3/__https:/llvm-compile-time-tracker.com/compare.php?from=167ff5280d7fcad731810d5d2bf10561ed2adacc&to=b08fcae3a02d5ebe58afd8f8658d798b62ff8eb7&stat=max-rss__;!!JmoZiZGBv3RvKRSx!u5xov9_zHGWKWsFWg-FlBBUrKZWcBw4KyfXq4eY9dQRAIJUNxoTfDwD40IbggPFwHQ$" target="_blank">llvm-compile-time-tracker</a> memory
metrics<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Any concerns with this?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev__;!!JmoZiZGBv3RvKRSx!u5xov9_zHGWKWsFWg-FlBBUrKZWcBw4KyfXq4eY9dQRAIJUNxoTfDwD40IZRLUF5mg$" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>