<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 19, 2021, at 4:24 PM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com" class="">xinliangli@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><br class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div dir="ltr" class="gmail_attr">On Wed, May 19, 2021 at 4:14 PM Vedant Kumar <<a href="mailto:vsk@apple.com" class="">vsk@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 19, 2021, at 3:11 PM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com" target="_blank" class="">xinliangli@gmail.com</a>> wrote:</div><br class=""><div class=""><br class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><div dir="ltr" class="gmail_attr">On Wed, May 19, 2021 at 1:31 PM Alex Lorenz via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Hi,<br class=""><br class="">> On May 19, 2021, at 1:18 PM, Reid Kleckner via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">><span class=""> </span><br class="">> Hi folks,<br class="">><span class=""> </span><br class="">> I wanted to make some improvements to code coverage, which uses frontend profile instrumentation. Is anyone still using frontend PGO for optimization (not coverage), or has everyone moved to IR PGO for that?<br class="">><span class=""> </span><br class="">> Here are the existing modes as I understand them:<br class="">><span class=""> </span><br class="">> 1. Frontend PGO: -fprofile-instr-generate / use. Code in clang/lib/CodeGen/CodeGenPGO.cpp inserts PGO counter update intrinsics. This happens before optimization. This is very source directed.<br class="">><span class=""> </span><br class="">> 2. Coverage: -fprofile-instr-generate -fcoverage-mapping. This is basically frontend PGO, plus some extra coverage mapping data to map from counters back to precise source locations.<br class="">><span class=""> </span><br class="">> 3. IR PGO: -fprofile-generate. The LLVM IR pass llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp is responsible for inserting calls to the counter update intrinsics at some specific point in the optimization pipeline. IIUC, this is done after the "pre-inliner" pass and other simplification passes so that there are fewer counter updates and a bit more precision.<br class="">><span class=""> </span><br class="">> 4. Context sensitive PGO: -fcs-profile-generate. This is basically the same as IR PGO, except it happens after regular inlining, so you can use it as a "second round" of PGO: use IR PGO first, get profile guided inlinings, profile again, and use that to influence code layout or further inlining.<br class="">><span class=""> </span><br class="">> ---<br class="">><span class=""> </span><br class="">> Is anyone using the first mode, frontend PGO, or has everyone migrated to IR PGO already? It seems to me that the main use case for frontend PGO is really just coverage, and we should consider deprecating frontend PGO. In Chrome, we accidentally started using frontend PGO instead of IR PGO, and found that IR PGO was better.<br class="">><span class=""> </span><br class=""><br class="">Yes, we use the frontend PGO in Apple clang in Xcode. I’m curious though, what kind of improvements did you see with IR PGO?<br class=""></blockquote><div class=""><br class=""></div><div class=""><a class="gmail_plusreply" id="gmail-m_-421630725865720619plusReplyChip-0" href="mailto:vsk@apple.com" target="_blank">+Vedant Kumar</a> <br class=""></div><div class=""><br class=""></div><div class="">Any other reason you are using frontend PGO for performance? IR PGO has other advantages as well: 1) better performance in training run; 2) better value profiling support; and 3) smaller raw profile data size.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Michael (just cc'd) and Alex L. have more context about the AppleClang release process and would be better suited to answer.</div><div class=""><br class=""></div><div class="">Historically, we've expected there to be some amount of source drift between the latest PGO/training build available from CI and the release tag. FE PGO is supposed to degrade gracefully when source drift occurs, and I believe we rely on that feature.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Both IR and Frontend PGO use content based hashing for profile lookup. Is there anything in FE PGO which makes it more tolerant to source drifts?</div></div></div></blockquote><div><br class=""></div><div>This is an important issue for us, but I don’t know if and how the frontend PGO is more tolerant to that. I think we need to do some more analysis on our end to see what specifically we need out of <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">frontend</span> PGO that isn’t well served by IR PGO.</div><div><br class=""></div><div>As far the possible deprecation of frontend PGO, will that imply that the `-fprofile-instr-generate / use` options will get removed, or will they still be supported but will leverage IR PGO instead?</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class=""><br class=""></div><div class="">David</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">vedant</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><div class="">Deprecating frontend-PGO (and making it for coverage testing only) would be desirable as Reid said.</div><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">> I'm asking because I would like to make code coverage builds faster and smaller, and supporting PGO with the same codepaths makes that complicated.<br class="">><span class=""> </span><br class="">> Reid<br class="">> _______________________________________________<br class="">> cfe-dev mailing list<br class="">><span class=""> </span><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">><span class=""> </span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div><br class=""></body></html>