<div dir="ltr">Thank you George, we don't have a foreseeable change which increases the code size further. <br><br>Wei.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2019 at 11:11 AM George Burgess <<a href="mailto:gbiv@google.com">gbiv@google.com</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"><div dir="ltr">Android's Chrome is built with -Oz by default, but some pieces are built with -O2/-O3.<div><br></div><div>IIRC, most of the size win for Android was through the use of -fprofile-sample-accurate on -O2/-O3'd TUs. Do you expect that, purely from a code-size perspective, prod will want to further reduce the effectiveness of -fprofile-sample-accurate, or is this the only regression on the roadmap for the moment?</div><div><br></div><div>I can personally live with a one-off 70KB regression, but if we plan to have more, Chrome for Android might want a -fprofile-sample-very-accurate flag :)</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2019 at 9:13 AM Wei Mi <<a href="mailto:wmi@google.com" target="_blank">wmi@google.com</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"><div dir="ltr">The size increase is expected. We are planning to use profile-sample-accurate more widely in Google, but simply enabling it will cause performance regression so we use this patch to minimize it. The size increase is mostly from more inlining, but the increase is small compared with code size reduction from enabling profile-sample-accurate from our experiment. <div><br></div><div>If code size is more of a concern for chrome on Android than performance, I can guard the change not to be enabled for -Os and Oz (I guess chrome on Android has already been built with Os or Oz). </div><div><br></div><div>Please let me know what you think. </div><div><br></div><div>Thanks,</div><div>Wei.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2019 at 4:14 AM Hans Wennborg <<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.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">This caused a ~70 KB size regression for Chrome on Android. Is this expected?<br>
<br>
Also +gbiv for Chrome Android pgo.<br>
<br>
We're tracking this in<br>
<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1006159" rel="noreferrer" target="_blank">https://bugs.chromium.org/p/chromium/issues/detail?id=1006159</a><br>
<br>
On Wed, Sep 18, 2019 at 6:05 PM Wei Mi via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> Author: wmi<br>
> Date: Wed Sep 18 09:06:28 2019<br>
> New Revision: 372232<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=372232&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=372232&view=rev</a><br>
> Log:<br>
> [SampleFDO] Minimize performance impact when profile-sample-accurate<br>
> is enabled.<br>
><br>
> We can save memory and reduce binary size significantly by enabling<br>
> ProfileSampleAccurate. However when ProfileSampleAccurate is true,<br>
> function without sample will be regarded as cold and this could<br>
> potentially cause performance regression.<br>
><br>
> To minimize the potential negative performance impact, we want to be<br>
> a little conservative here saying if a function shows up in the profile,<br>
> no matter as outline instance, inline instance or call targets, treat<br>
> the function as not being cold. This will handle the cases such as most<br>
> callsites of a function are inlined in sampled binary (thus outline copy<br>
> don't get any sample) but not inlined in current build (because of source<br>
> code drift, imprecise debug information, or the callsites are all cold<br>
> individually but not cold accumulatively...), so that the outline function<br>
> showing up as cold in sampled binary will actually not be cold after current<br>
> build. After the change, such function will be treated as not cold even<br>
> profile-sample-accurate is enabled.<br>
><br>
> At the same time we lower the hot criteria of callsiteIsHot check when<br>
> profile-sample-accurate is enabled. callsiteIsHot is used to determined<br>
> whether a callsite is hot and qualified for early inlining. When<br>
> profile-sample-accurate is enabled, functions without profile will be<br>
> regarded as cold and much less inlining will happen in CGSCC inlining pass,<br>
> so we can worry less about size increase and be aggressive to allow more<br>
> early inlining to happen for warm callsites and it is helpful for performance<br>
> overall.<br>
><br>
> Differential Revision: <a href="https://reviews.llvm.org/D67561" rel="noreferrer" target="_blank">https://reviews.llvm.org/D67561</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>