<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, May 24, 2017 at 10:26 AM Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com">daniel_l_sanders@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div>On 24 May 2017, at 17:31, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="m_-3518998295515836626Apple-interchange-newline"><div><div dir="ltr" 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"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 23, 2017 at 10:51 AM Daniel Sanders via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></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="word-wrap:break-word;line-break:after-white-space"><div>Could you give<span class="m_-3518998295515836626Apple-converted-space"> </span><a href="https://reviews.llvm.org/differential/diff/99949/" target="_blank">https://reviews.llvm.org/differential/diff/99949/</a> a try? It brings back the reverted commit and fixes two significant compile-time issues. Assuming it works for you too, I'll finish off the patches and post them individually.</div><div><br></div><div>The first one removes the single-use lambdas in the generated code. These turn out to be _really_ expensive. Replacing them with equivalent gotos saves 11 million allocations (~57%) during the course of compiling AArch64InstructionSelector.cpp.o. The cumulative number of bytes allocated also drops by ~4GB (~36%).</div></div></blockquote><div><br>(this is outside my wheelhouse, so just as an aside): Could you explain further what aspect of the change was that saved allocations? Lambdas themselves don't allocate memory (std::function of a stateful lambda may allocate memory - but I didn't see any std::function in your change, though I might've missed it), so I'm guessing it's something else/some other aspect of the code in/outside the lambdas and where it moved that changed the allocation pattern?<br></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>My tools don't tell me which allocations no longer occur but compiling the lambdas requires memory allocations. I believe the allocations come from the various optimization and analysis passes, SelectionDAG, MC, etc. for each of the MachineFunction's corresponding to the lambdas.</div></div></div></blockquote><div><br></div><div>Ah, sorry, I see - compile time performance, not the performance of the generated code. Thanks for the correction/explanation!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><blockquote type="cite"><div><div dir="ltr" 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"><div class="gmail_quote"><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="word-wrap:break-word;line-break:after-white-space"><div>The second one is to split up the functions by the number of operands in the top-level instruction. This constrains the scale of the task the register allocator needs to deal with in X86InstructionSelection.cpp.o.</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><br><div><blockquote type="cite"><div>On 22 May 2017, at 10:42, Diana Picus <<a href="mailto:diana.picus@linaro.org" target="_blank">diana.picus@linaro.org</a>> wrote:</div><br class="m_-3518998295515836626m_-1398107004193548205Apple-interchange-newline"><div><div>Nope, no sanitizers.<br><br>On 22 May 2017 at 11:38, Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>> wrote:<br><blockquote type="cite">Is that with -fsanitize=memory too?<br><br>I'm currently building ToT with r303258 reverted. Once that's done I'll commit the revert and start investigating fixes.<br><br><blockquote type="cite">On 22 May 2017, at 10:22, Diana Picus <<a href="mailto:diana.picus@linaro.org" target="_blank">diana.picus@linaro.org</a>> wrote:<br><br>Hi Daniel,<br><br>I did your experiment on a TK1 machine (same as the bots) and for r303258 I get:<br>real    18m28.882s<br>user    35m37.091s<br>sys     0m44.726s<br><br>and for r303259:<br>real    50m52.048s<br>user    88m25.473s<br>sys     0m46.548s<br><br>If I can help investigate, please let me know, otherwise we can just<br>try your fixes and see how they affect compilation time.<br><br>Thanks,<br>Diana<br><br>On 22 May 2017 at 10:49, Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>> wrote:<br><blockquote type="cite">r303341 is the re-commit of the r303259 which tripled the number of rules<br>that can be imported into GlobalISel from SelectionDAG. A compile time<br>regression is to be expected but when I looked into it I found it was ~25s<br>on my machine for the whole incremental build rather than the ~12mins you<br>are seeing. I'll take another look.<br><br>I'm aware of a couple easy improvements we could make to the way the<br>importer works. I was leaving them until we change it over to a state<br>machine but the most obvious is to group rules by their top-level gMIR<br>instruction. This would reduce the cost of the std::sort that handles the<br>rule priorities in generating the source file and will also make it simpler<br>for the compiler to compile it.<br><br><br>On 21 May 2017, at 11:16, Vitaly Buka <<a href="mailto:vitalybuka@google.com" target="_blank">vitalybuka@google.com</a>> wrote:<br><br>It must be r303341, I commented on corresponding llvm-commits thread.<br><br>On Fri, May 19, 2017 at 7:34 AM, Diana Picus via llvm-dev<br><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><blockquote type="cite"><br>Ok, thanks. I'll try to do a bisect next week to see if I can find it.<br><br>Cheers,<br>Diana<br><br>On 19 May 2017 at 16:29, Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>><br>wrote:<br><blockquote type="cite"><br><blockquote type="cite">On 19 May 2017, at 14:54, Daniel Sanders via llvm-dev<br><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><br>r303259 will have increased compile-time since it tripled the number of<br>importable<br>SelectionDAG rules but a quick measurement building the affected file:<br> ninja<br>lib/Target/<Target>/CMakeFiles/LLVM<Target>CodeGen.dir/<Target>InstructionSelector.cpp.o<br>for both ARM and AArch64 didn't show a significant increase. I'll check<br>whether<br>it made a different to linking.<br></blockquote><br>I don't think it's r303259. Starting with a fully built r303259, then<br>updating to r303258 and running 'ninja' gives me:<br>      real    2m28.273s<br>      user    13m23.171s<br>      sys     0m47.725s<br>then updating to r303259 and running 'ninja' again gives me:<br>      real    2m19.052s<br>      user    13m38.802s<br>      sys     0m44.551s<br><br><blockquote type="cite">sanitizer-x86_64-linux-fast also timed out after one of my commits this<br>morning.<br><br><blockquote type="cite">On 19 May 2017, at 14:14, Diana Picus <<a href="mailto:diana.picus@linaro.org" target="_blank">diana.picus@linaro.org</a>> wrote:<br><br>Hi,<br><br>We've noticed that recently some of our bots (mostly<br>clang-cmake-armv7-a15 and clang-cmake-thumbv7-a15) started timing out<br>whenever someone commits a change to TableGen:<br><br>r303418:<br><a href="http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7268" target="_blank">http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7268</a><br>r303346:<br><a href="http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7242" target="_blank">http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7242</a><br>r303341:<br><a href="http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7239" target="_blank">http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7239</a><br>r303259:<br><a href="http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7198" target="_blank">http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7198</a><br><br>TableGen changes before that (I checked about 3-4 of them) don't have<br>this problem:<br>r303253:<br><a href="http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7197" target="_blank">http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7197</a><br><br>That one in particular actually finishes the whole build in 635s,<br>which is only a bit over 50% of the timeout limit (1200s). So, between<br>r303253 and now, something happened that made full builds<br>significantly slower. Does anyone have any idea what that might have<br>been? Also, has anyone noticed this on other bots?<br><br>Thanks,<br>Diana<br></blockquote><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" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></blockquote><br></blockquote>_______________________________________________<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" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></blockquote><br><br><br></blockquote></blockquote><br></blockquote></div></div></blockquote></div><br></div></div></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></blockquote></div></div></div></blockquote></div></div></blockquote></div></div>