
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 16, 2017, at 4:58 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Jun 16, 2017 at 4:43 PM Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:<br class=""></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;" class=""><div class="">Hi all,</div><div class=""><br class=""></div><div class="">We had some internal discussions about flipping the default for O0 and we concluded that we wanted to postpone it.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">*** Why Is That? ***</div><div class=""><br class=""></div><div class="">We don’t want to send the wrong message that GlobalISel’s design is set in stone and ready for broader adoption.</div><div class="">In particular,</div><div class="">1. The APIs are still evolving and can still possibly change significantly</div><div class="">2. The TableGen backend to reuse the existing SD patterns is still at its early stage</div><div class="">3. We want to investigate closely the performance of global-isel (compile-time, runtime, code size, fallbacks)</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><br class=""></div><div class="">*** Short-Term Proposal ***</div><div class=""><br class=""></div><div class="">What we would like to do instead short-term is:</div><div class="">A. Repurpose or create an option “<span style="font-family: Menlo; font-size: 11px; background-color: rgb(255, 255, 255);" class="">-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 class="">B. Advertise this option in the next open source release to allow compiler enthusiastic to try it and report problems</div><div class="">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 class=""><br class=""></div><div class="">What do people think?</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">How about -fexperimental-global-isel as a flag to clang?</div></div></div></div></blockquote><div><br class=""></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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">-eric</div><div class=""> </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;" class=""><div class=""></div><div class=""><br class=""></div><div class="">*** Your Help Is Needed ***</div><div class=""><br class=""></div><div class="">- 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 class="">- Report any performance problem you identify</div><div class="">- Propose patches!</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Quentin</div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jun 16, 2017, at 3:06 PM, Quentin Colombet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-5088029151889992417Apple-interchange-newline"><div class=""><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;" class=""><blockquote type="cite" class=""><div class=""><br class="m_-5088029151889992417Apple-interchange-newline">On Jun 14, 2017, at 7:27 AM, Diana Picus <<a href="mailto:diana.picus@linaro.org" target="_blank" class="">diana.picus@linaro.org</a>> wrote:</div><br class="m_-5088029151889992417Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 12 June 2017 at 18:54, Diana Picus<span class="m_-5088029151889992417Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:diana.picus@linaro.org" target="_blank" class="">diana.picus@linaro.org</a>></span><span class="m_-5088029151889992417Apple-converted-space"> </span>wrote:<br class=""><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" class="">Hi all,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""><div class=""><br class=""></div><div class="">PAQ8p:</div><div class="">Fast isel: 666.344</div><div class="">Global isel: 731.384</div><div class=""><br class=""></div><div class="">SciMark2-C:</div><div class="">Fast isel: 463.908</div><div class="">Global isel: 496.22</div></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Something along these lines works:</div><div class=""><a href="https://reviews.llvm.org/differential/diff/102547/" target="_blank" class="">https://reviews.llvm.org/differential/diff/102547/</a><br class=""></div><div class=""><br class=""></div><div class="">What do you guys think about this approach?</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Looks reasonable to me.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Diana</div><div class=""><br class=""></div><div class="">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><br class=""></body></html>