<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 16, 2017 at 5:11 PM Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@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"><div><blockquote type="cite"><div>On Jun 16, 2017, at 4:58 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br class="m_7046190408462219009Apple-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 Fri, Jun 16, 2017 at 4:43 PM Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi all,</div><div><br></div><div>We had some internal discussions about flipping the default for O0 and we concluded that we wanted to postpone it.</div><div><br></div><div><br></div><div>*** Why Is That? ***</div><div><br></div><div>We don’t want to send the wrong message that GlobalISel’s design is set in stone and ready for broader adoption.</div><div>In particular,</div><div>1. The APIs are still evolving and can still possibly change significantly</div><div>2. The TableGen backend to reuse the existing SD patterns is still at its early stage</div><div>3. We want to investigate closely the performance of global-isel (compile-time, runtime, code size, fallbacks)</div><div><br></div><div>The rationale behind those items is that we want to minimize the pain of moving forward for everybody. We also want the out-of-the-box experience to be pleasant (like all/most of the tablegen patterns just work, we have documentation on how to target a new backend, etc.) Finally, we want to gain confidence we are going to be able to address the performance issues we have with the current design and if not, derive a plan for that.</div><div><br></div><div>We purposely left out of the conversation what will be the right time and requirements to flip the switch. We want to gather more data first. Your help would be appreciated!</div><div><br></div><div><br></div><div>*** Short-Term Proposal ***</div><div><br></div><div>What we would like to do instead short-term is:</div><div>A. Repurpose or create an option “<span style="font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">-aarch64-enable-global-isel-at-O</span>” to enable GISel with fallbacks and warnings enables (i.e., equivalent of -global-isel -global-isel-abort=2)</div><div>B. Advertise this option in the next open source release to allow compiler enthusiastic to try it and report problems</div><div>C. Have GISel always built so we can push thing in the right place, MachineVerifier in mind, and stop doing some weird gymnastic</div><div><br></div><div>What do people think?</div><div><br></div></div></blockquote><div><br></div><div>How about -fexperimental-global-isel as a flag to clang?</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I thought about that and that would work, but I thought we had an implicit contract that clang options are not going away.</div><div>If that’s not the case, then, yes, we should do that!</div></div></div></blockquote><div><br></div><div>*shrug* we have one for the new pass manager to make testing easier, this seems reasonable as well for something that's going to be tested over an extended period of time.</div><div><br></div><div>-eric</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"><div><br><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"><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div>*** Your Help Is Needed ***</div><div><br></div><div>- Please share your experience in using the GISel APIs and how we can make them better. Moving forward we’ll have those conversations on open source instead of internally/with a narrower audience.</div><div>- Report any performance problem you identify</div><div>- Propose patches!</div><div><br></div><div>Cheers,</div><div>-Quentin</div></div><div style="word-wrap:break-word"><div><div><br></div></div><div><br></div><div><br></div><div><blockquote type="cite"><div>On Jun 16, 2017, at 3:06 PM, Quentin Colombet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_7046190408462219009m_-5088029151889992417Apple-interchange-newline"><div><div 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"><blockquote type="cite"><div><br class="m_7046190408462219009m_-5088029151889992417Apple-interchange-newline">On Jun 14, 2017, at 7:27 AM, Diana Picus <<a href="mailto:diana.picus@linaro.org" target="_blank">diana.picus@linaro.org</a>> wrote:</div><br class="m_7046190408462219009m_-5088029151889992417Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 June 2017 at 18:54, Diana Picus<span class="m_7046190408462219009m_-5088029151889992417Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:diana.picus@linaro.org" target="_blank">diana.picus@linaro.org</a>></span><span class="m_7046190408462219009m_-5088029151889992417Apple-converted-space"> </span>wrote:<br><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 dir="ltr">Hi all,<div><br></div><div>I added a buildbot [1] running the test-suite with -O0 -global-isel. It runs into the same 2 timeouts that I reported previously on this thread (paq8p and scimark2). It would be nice to make it green before flipping the switch.</div><div><br></div></div></blockquote><div><br></div><div>I did some more investigations on a machine similar to the one running the buildbot. For paq8p and scimark2, I get these results for O0:</div><div><div><br></div><div>PAQ8p:</div><div>Fast isel: 666.344</div><div>Global isel: 731.384</div><div><br></div><div>SciMark2-C:</div><div>Fast isel: 463.908</div><div>Global isel: 496.22</div></div><div><br></div><div>The current timeout is 500s (so in this particular case we didn't hit it for scimark2, and it ran successfully to completion). I don't think the difference between FastISel and GlobalISel is too atrocious, so I would propose increasing the timeout for these 2 benchmarks. I'm not sure if we can do this on a per-bot basis, but I see some precedent for setting custom timeout thresholds for various benchmarks on different architectures (sometimes with comments that it's done so we can run O0 on that particular benchmark). </div><div><br></div><div>Something along these lines works:</div><div><a href="https://reviews.llvm.org/differential/diff/102547/" target="_blank">https://reviews.llvm.org/differential/diff/102547/</a><br></div><div><br></div><div>What do you guys think about this approach?</div></div></div></div></div></blockquote><div><br></div><div>Looks reasonable to me.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Thanks,</div><div>Diana</div><div><br></div><div>PS: The buildbot is using the Makefiles because that's what our other AArch64 test-suite bots use. Moving all of them to CMake is a transition for another time.</div></div></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div>