<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 January 2017 at 10:53, Mehdi Amini via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> On Jan 14, 2017, at 4:57 AM, Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On 14 January 2017 at 01:54, Quentin Colombet via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> 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>
><br>
> Hi Quentin,<br>
><br>
> I'm not extremely confident in a full switch right now, mainly due to<br>
> Michael's concerns. The ARM port is in its initial stage and there<br>
> could still be many refactorings and destructive changes. I'm not<br>
> foreseeing a cross between the isel tests, but every failure makes the<br>
> bots red, and if Global ISel incurs in more failures due to its stage<br>
> in the development cycle, we'll start seeing the bots more red than<br>
> we'd like. Right now, it's already very likely that you'll receive bot<br>
> emails on commits, I don't want to increase that.<br>
<br>
</span>I don’t see why having global ISel is supposed to increase the rate. `make check` will runs on the committer machine with GlobalISel enabled.<br>
<br>
The good question from Michael is IMO "if my (non-GlobalISel) change breaks GlobalISel, how likely is it to be a bug in my code vs. a bug in GlobalISel?”<br>
<br>
But that’s totally unrelated to the bots, since it’ll fails on the committer machine as well.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>To emphasize this - I don't think the bots should be a blocker, the issue that bothers me is local developer workflow.</div><div><br></div><div>Regarding "we shouldn't enable it because it will make the bots slower" - well, yes, but that's just postponing the inevitable. We will enable GlobalISel eventually, and there will probably be a very long time-frame during which both are enabled concurrently. If we expect to have some magic solution to make overall testing much faster in the near future, it may make sense to delay until it's implemented. But I'm not aware of anything like that.</div><div><br></div><div>As to it making the bots "redder" because of failures in the newer GlobalISel ports - if devs don't see a lot of local breakage, then the effect on the bots shouldn't be big either. And if they do, I think it's a non-starter anyway.</div><div>Still, as a strawman proposal - would it make sense to add <span style="font-size:12.8px">LLVM_BUILD_GLOBAL_ISEL_EXPERIMENTAL, or something of that sort</span><span style="font-size:12.8px">? The more mature ports will build under </span><span style="font-size:12.8px">LLVM_BUILD_GLOBAL_ISEL</span><span style="font-size:12.8px"> (which will be enabled by default), the less mature ones only under </span><span style="font-size:12.8px">LLVM_BUILD_GLOBAL_ISEL_EXPERIMENTAL (which won't be), and moving a port from </span><span style="font-size:12.8px">GLOBAL_ISEL_EXPERIMENTAL </span><span style="font-size:12.8px">to </span><span style="font-size:12.8px">GLOBAL_ISEL would be equivalent to marking a regular backend non-experimental. We can start with just AArch64 in the non-experimental category, and move the others as they become more stable.</span></div><div><span style="font-size:12.8px">Or is this too much complexity for what we gain?</span></div><div><br></div><div><span style="font-size:12.8px">Michael</span></div></div></div></div>