<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Would this completely replace FastISel (on AArch64) then? So that we have to look for bugs only in GlobalISel and SelectionDAG?</div><div class=""><br class=""></div><div class="">- Matthias</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 29, 2017, at 4:27 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=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">GlobalISel, the SelectionDAG replacement, has come a long way since initially discussed on the mailing list and its last discussion at the EuroLLVM BoF (<a href="https://etherpad.net/p/GlobalISel" class="">https://etherpad.net/p/GlobalISel</a>).</div><div class="">We believe we are close to the point of enabling it by default on AArch64 at O0. We now would like to enlist your help to get there.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">*** Quick Status ***</div><div class=""><br class=""></div><div class="">On iOS we are at 100% pass rate in 00 g for the LLVM test suite, standard benchmarks and unit tests. In about 5% of all functions GlobalIsel falls back to SDIsel.</div><div class="">(Kristof Beyls would have the linux numbers.)</div><div class="">The self host compiler correctly builds and runs the LLVM test suite in O0.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">*** We Need Your Help ***</div><div class=""><br class=""></div><div class="">Please try GlobalISel for AArch64 at O0 (preferably O0 g) and file PR for:</div><div class="">- Performance problems (compile time, runtime, code size)</div><div class="">- Miscompile</div><div class="">- Crashers</div><div class="">- Poor debug information</div><div class="">- etc.</div><div class=""><br class=""></div><div class="">There is a component GlobalISel in <a href="http://llvm.org/bugs" class="">llvm.org/bugs</a> for that.</div><div class=""><br class=""></div><div class="">GlobalISel cannot handle some inputs (e.g., some vector construction), but it falls back to SDISel when it hits such cases. We are also interested to know whether or not GlobalISel fallback on your favorite workloads and why (see next section for the actual options to run). So please file PRs for that too.</div><div class=""><br class=""></div><div class="">As always, patches are welcome!</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">*** Concretely What Do I Run ***</div><div class=""><br class=""></div><div class="">Please test your favorite workload/scenario on AArch64 at O0 using one of the following additional category of options:</div><div class="">Recommended: (-llvm) -global-isel (-mllvm) -global-isel-abort=2</div><div class="">OkToFallBack:: (-llvm) -global-isel (-mllvm) -global-isel-abort=0</div><div class="">AbortOnFallBack: (-llvm) -global-isel</div><div class=""><br class=""></div><div class="">The Recommended way will issue a warning if it falls back to SelectionDAG, the OkToFallBack will silently fallback to SDISel if it needs to, and the AbortOnFallBack will kill the compiler if GlobalISel cannot handle the input completely.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">*** What Is Next? ***</div><div class=""><br class=""></div><div class="">We would like to turn on GobalISel by default in the next couple of weeks. Please help identify any critical issue that needs to be resolved before that can happen. We expect that minor hiccups and outliers in any metrics can be fixed quickly, but are worried about harmful run-time (miscompile) or compile-time crashes.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Many thanks,</div><div class="">-Quentin</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="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>