<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Kristof,<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 13, 2017, at 9:10 AM, Kristof Beyls <<a href="mailto:Kristof.Beyls@arm.com" class="">Kristof.Beyls@arm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">

<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Quentin,
<div class=""><br class="">
</div>
<div class="">My only remaining concern is around ABI compatibility.</div>
<div class="">The following commit seems to indicate that in the previous round of evaluation, we didn’t find an existing ABI compatibility issue:</div>
<div class=""><a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=311388" class="">http://llvm.org/viewvc/llvm-project?view=revision&revision=311388</a>.</div>
<div class="">I haven’t looked into the details of this issue - so maybe I’m worried over nothing?</div></div></div></blockquote><div><br class=""></div><div>No, you’re right. The problem with ABI is if you are consistently wrong, then you won’t notice :).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">I’m wondering if since then on your side you did any testing around ABI compatibility?</div>
<div class="">E.g. building software where you semi-randomly build some functions through GlobalISel and some functions through DAGISel?</div></div></div></blockquote><div><br class=""></div><div>Justin will look into that. Clang has utility script for that utils/ABITest.</div><div><br class=""></div><div>Given we will only be able to check iOS ABI, you may want to follow the same kind of validation on your side.</div><div><br class=""></div><div>I let you sync up with Justin for the method.</div><div><br class=""></div><div>Cheers,</div><div>-Quentin</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class=""><br class="">
</div>
<div class="">Kristof</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 8 Nov 2017, at 00:42, Quentin Colombet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi all,
<div class=""><br class="">
</div>
<div class="">I’d like to resurrect this thread and ask if people are on board for enabling this by default for AArch64 O0.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">*** What Changed Since June? ***</div>
<div class=""><br class="">
</div>
<div class="">- We added a way to describe the legalization actions for non-power-of-2 </div>
<div class="">- We gave a tutorial that covers the best practices to target GlobalISel</div>
<div class="">- We improved the TableGen backend to reuse existing SDISel patterns</div>
<div class="">- We built and ran huge internal software with GISel</div>
<div class="">- We evaluated the performance of GISel and are confident things are in a good shape (with
<a href="https://reviews.llvm.org/D39034" class="">https://reviews.llvm.org/D39034</a>) and moving forward would look even better (see the last LLVM Dev talk:
<i class="">GlobalISel: Present, Past, and Future</i> when it is available)</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">*** So What’s he Plan? ***</div>
<div class=""><br class="">
</div>
<div class="">- Switch the default instruction selector to GISel for AArch64 at O0</div>
<div class="">- Enable the fallback path by default for AArch64 (with warnings enabled when that path is hit)</div>
<div class="">- Provide a clang option to turn GISel off</div>
<div class=""><br class="">
</div>
<div class="">What do you think?</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">-Quentin</div>
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Jun 16, 2017, at 4:43 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" 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 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 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" class="">llvm-dev@lists.llvm.org</a>> wrote:</div>
<br class="Apple-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; 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="">
<blockquote type="cite" class="">
<div class=""><br class="Apple-interchange-newline">
On Jun 14, 2017, at 7:27 AM, Diana Picus <<a href="mailto:diana.picus@linaro.org" class="">diana.picus@linaro.org</a>> wrote:</div>
<br class="Apple-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="Apple-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="Apple-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/<wbr class="">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>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>

</div></blockquote></div><br class=""></div></body></html>