<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="">Bumping up this thread. Based on the initial investigation, I think we can switch to the IR PGO instead of the frontend PGO and so you’ll be able to proceed with this deprecation of the frontend PGO. We would like to request some additional time to do a full investigation and prepare for the transition on our end though, ideally we would need about 3 - 6 months to ensure we are prepared for that. Would you be willing to revisit this again in the future once we’re ready for that?<div class=""><br class=""></div><div class="">Thanks,</div><div class="">Alex<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 20, 2021, at 9:54 AM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com" class="">xinliangli@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 20, 2021 at 9:47 AM Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:<br class=""></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" class=""><div dir="ltr" class="">On Wed, May 19, 2021 at 7:48 PM Alex Lorenz <<a href="mailto:aleksei_lorenz@apple.com" target="_blank" class="">aleksei_lorenz@apple.com</a>> wrote:</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 class=""><div class=""><div class="">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></div></div></blockquote><div class=""><br class=""></div><div class="">That makes sense to me, but we need to untangle the fact that `-fprofile-instr-generate -fcoverage-mapping` is currently used for coverage, so a simple alias isn't quite correct.</div><div class=""><br class=""></div><div class="">I've always wanted a single, high-level coverage flag, and I always thought it should be spelled --coverage of -fcoverage, but that seems like it's already taken by gcov instrumentation. =/ I guess we need to bikeshed a new spelling.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Right. -fcoverage-mapping itself does not much so it should probably imply frontend instrumentation. </div><div class=""><br class=""></div><div class="">For migration purposes, if -fcoverage-mapping is used together with -fprofile-instr-generate (which becomes IR PGO), the latter will be dropped (or a warning is given). The tricky part is if the user uses the option to specify the profile path, then we have a problem.</div><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""></div><div class="">David</div><div class=""> </div></div></div>
</div></blockquote></div><br class=""></div></body></html>