<div dir="ltr">See <a href="https://llvm.org/bugs/show_bug.cgi?id=17409">https://llvm.org/bugs/show_bug.cgi?id=17409</a><div><br></div><div>I believe much of the compile issues related to BlockFrequency computation has been fixed by Cong's recent work to convert weight based interfaces to BranchProbability based interfaces.  The other issue related to Spiller probably still remains.</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 1:13 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Mar 8, 2016 at 11:18 AM, Xinliang David Li via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Mar 8, 2016 at 10:55 AM, mats petersson via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I have noticed that LLVM doesn't seem to "like" large functions, as a general rule. Admittedly, my experience is similar with gcc, so I'm not sure it's something that can be easily fixed. And I'm probably sounding like a broken record, because I have said this before.<br><br></div><div>My experience is that the time it takes to compile something is growing above linear with size of function. <br><br></div></div></blockquote><div><br></div></span><div>The number of BBs -- Kosyia can point you to the compile time bug that is exposed by asan .</div></div></div></div></blockquote><div><br></div></span><div>I believe we also have some superlinear behavior with BB size as well.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>David</div><div><div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Of course, the LLVM code is growing over time, both to support more features and to support more architectures, new processor types and instruction sets, at least of which will lead to larger functions in general [and this is the function "after inlining", so splitting small 'called once' functions out doesn't really help much].<br><br></div><div>I will have a little play to see if I can identify more of a cuplrit [at the very least if it's "large basic blocks" or "large functions" that is the problem] - of course, this could be unrelated and irellevant to the problem Daniel is pointing at, and it may or may not be easily resolved...<br><br>--<br></div><div>Mats<br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 8 March 2016 at 18:42, Richard Smith via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Mar 8, 2016 at 8:13 AM, Rafael Espíndola<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I have just benchmarked building trunk llvm and clang in Debug,<br>
> Release and LTO modes (see the attached scrip for the cmake lines).<br>
><br>
> The compilers used were clang 3.5, 3.6, 3.7, 3.8 and trunk. In all<br>
> cases I used the system libgcc and libstdc++.<br>
><br>
> For release builds there is a monotonic increase in each version. From<br>
> 163 minutes with 3.5 to 212 minutes with trunk. For comparison, gcc<br>
> 5.3.2 takes 205 minutes.<br>
><br>
> Debug and LTO show an improvement in 3.7, but have regressed again in 3.8.<br>
<br>
</span>I'm curious how these times divide across Clang and various parts of<br>
LLVM; rerunning with -ftime-report and summing the numbers across all<br>
compiles could be interesting.<br>
<div><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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>