
<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="">Hi Quentin,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 17, 2017, at 10:04 AM, 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Michael,</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 13, 2017, at 6:38 PM, Michael Kuperstein <<a href="mailto:mkuper@google.com" class="">mkuper@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">As a person not developing on GlobalISel, I can already play with it by setting the flag. ;-)</div><div class=""><br class=""></div>The main (and huge) benefit I see is that it will get tested by default.</div></div></blockquote><div class=""><br class=""></div><div class="">I agree.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""> So, I think it's mainly a question of maturity - if my (non-GlobalISel) change breaks GlobalISel, how likely is it to be a bug in my code vs. a bug in GlobalISel?</div></div></blockquote><div class=""><br class=""></div><div class="">That’s very likely this is a bug in your code. GlobalISel test cases usually check the GlobalISel passes in isolation. Therefore, if they break without GlobalISel related passes being changed, that means that some of the core MI functionalities have been broken (e.g., some semantic with MachineRegisterInfo, the parsing of .mir files, this kind of thing).</div><div class="">In other words, it is usually best for the author of the code to realize directly that the code break.</div></div></div></div></blockquote><div><br class=""></div><div>With this, and the data your provided in your other email showing build time being in the noise (thanks for the data BTW!), I don’t see any reason not to do it!</div><div><br class=""></div><div>One last question: how much of a burden does it put on backend developer changing an API in, for instance SelectionDAG, to update uses in GlobalISel? Does it happens frequently in practice according to your experience maintaining the bot green?</div><div>(I don’t expect much, but asking just in case).</div><div><br class=""></div><div>Thanks,</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><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=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 13, 2017 at 5:54 PM, Quentin Colombet via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class="">

<br class="">

Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default.<br class="">

<br class="">

** Impact of Flipping the Switch **<br class="">

<br class="">

* Upsides *<br class="">

<br class="">

For people developing on GlobalISel, it will:<br class="">

- Simplify the CMake command to type :)<br class="">

- Build/Test GlobalISel on all the LLVM bots<br class="">

<br class="">

For people not developing on GlobalISel, it will:<br class="">

- Test that GlobalISel still works with your changes (make check will test that for you)<br class="">

- Allow you to play with it!<br class="">

<br class="">

Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel.<br class="">

<br class="">

* Downsides *<br class="">

<br class="">

For people developing on GlobalISel, it will:<br class="">

- Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots<br class="">

<br class="">

For people not developing for GlobalISel, it will:<br class="">

- Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built<br class="">

- Increase the size of the binary (depending on what backend you pull)<br class="">

- Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF)<br class="">

<br class="">

<br class="">

What do people think?<br class="">

<br class="">

Thanks,<br class="">

-Quentin<br class="">

______________________________<wbr class="">_________________<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" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">

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

</div></blockquote></div><br class=""></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=""></div></body></html>