<div dir="ltr">These concerns sound applicable to the situation when GlobalISel is turned on by default and has an effect on code generation.<br><br>While it's a library with tests like any other LLVM component I don't see these concerns as being significantly greater risk than any other library in LLVM.<br><br>I'm honestly surprised GlobalISel was developed in such a way that it hasn't been built and tested by default for all developers from Day 1. The new pass manager and the ORC JIT are examples of this - there was never any question about when to enable building and testing them. They were built and tested from the moment they went in tree.<br><br>The question of when to turn these things (GlobalISel, New PM, ORC, etc) is a very different question and one I'd expect to be staged in the way you're describing, Renato. Provide a flag, off by default. Ask/encourage people to test it out. Eventually flip the default - encouraging people to unflip manually and report if they have trouble. Maintain this state until reported issues are addressed/wait for a grace period, then remove the flag/old code entirely.<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 15, 2017 at 5:15 AM Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15 January 2017 at 04:24, Michael Kuperstein<br class="gmail_msg">
<<a href="mailto:michael.kuperstein@gmail.com" class="gmail_msg" target="_blank">michael.kuperstein@gmail.com</a>> wrote:<br class="gmail_msg">
> Regarding "we shouldn't enable it because it will make the bots slower" -<br class="gmail_msg">
> well, yes, but that's just postponing the inevitable. We will enable<br class="gmail_msg">
> GlobalISel eventually, and there will probably be a very long time-frame<br class="gmail_msg">
> during which both are enabled concurrently.<br class="gmail_msg">
<br class="gmail_msg">
No magic solutions expected. I just don't want to crank all bots up to<br class="gmail_msg">
11 on day one. We start with the fast bots, when they're happy, we<br class="gmail_msg">
move on until we're confident that the whole thing is stable, then we<br class="gmail_msg">
make it build by default.<br class="gmail_msg">
<br class="gmail_msg">
There are two problems here:<br class="gmail_msg">
<br class="gmail_msg">
1. Environmental issues.<br class="gmail_msg">
<br class="gmail_msg">
We do find more of those than we'd hope. Different compilers, linkers,<br class="gmail_msg">
libraries that produce not only crashes, but unstable builds and<br class="gmail_msg">
unpredictable or irreproducible test failures. The environment on our<br class="gmail_msg">
bots are wildly different (on purpose) and dealing with different<br class="gmail_msg">
unpredictable issues all at once is something that I'm not willing to<br class="gmail_msg">
take on lightly. Due to the nature of buildbots and some of our<br class="gmail_msg">
hardware and the fact that virtually all ARM/AArch64 bots are ours,<br class="gmail_msg">
this will be something that Linaro will pay the price in full.<br class="gmail_msg">
<br class="gmail_msg">
2. Experimental nature.<br class="gmail_msg">
<br class="gmail_msg">
If the past serves as a guide, experimental features at the core of<br class="gmail_msg">
LLVM will be largely independent until they start to merge, when they<br class="gmail_msg">
can become a huge issue and be in merging state for months, if not<br class="gmail_msg">
years, or worse, never be merged. Right now, we're not at that state,<br class="gmail_msg">
we're still largely independent, so your worries regarding the<br class="gmail_msg">
development tests (which also hit buildbots at a different pace<br class="gmail_msg">
because of the environment issues above), will be lower for now, but<br class="gmail_msg">
will increase massively soon enough.<br class="gmail_msg">
<br class="gmail_msg">
There is the argument that having the bots building means we'll have<br class="gmail_msg">
*less* teething issues and the people building GlobalISel (which also<br class="gmail_msg">
includes Linaro) will have a lot less work. But there's a cost to be<br class="gmail_msg">
paid, and that cost is a lot higher on the ARM/AArch64 side than x86,<br class="gmail_msg">
just because most developers use an x86 as their main machine.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> Still, as a strawman proposal - would it make sense to add<br class="gmail_msg">
> LLVM_BUILD_GLOBAL_ISEL_EXPERIMENTAL, or something of that sort? The more<br class="gmail_msg">
> mature ports will build under LLVM_BUILD_GLOBAL_ISEL (which will be enabled<br class="gmail_msg">
> by default), the less mature ones only under<br class="gmail_msg">
> LLVM_BUILD_GLOBAL_ISEL_EXPERIMENTAL (which won't be), and moving a port from<br class="gmail_msg">
> GLOBAL_ISEL_EXPERIMENTAL to GLOBAL_ISEL would be equivalent to marking a<br class="gmail_msg">
> regular backend non-experimental. We can start with just AArch64 in the<br class="gmail_msg">
> non-experimental category, and move the others as they become more stable.<br class="gmail_msg">
> Or is this too much complexity for what we gain?<br class="gmail_msg">
<br class="gmail_msg">
It is.<br class="gmail_msg">
<br class="gmail_msg">
We already separate that by not building any other back-end than ARM<br class="gmail_msg">
and AArch64. So I think we can do that without the added complexity.<br class="gmail_msg">
<br class="gmail_msg">
I'm not trying to block the move, I'm just trying to make it smother<br class="gmail_msg">
and raise awareness that the cost we pay for any large move is not<br class="gmail_msg">
well distributed.<br class="gmail_msg">
<br class="gmail_msg">
For the past few months I have reverted patches that only broke the<br class="gmail_msg">
ARM bots and it was clear on most of those instances which patch was<br class="gmail_msg">
to blame, but people didn't bother and after 8, 12 sometimes 24 hours,<br class="gmail_msg">
I reverted. This is not a nice place to be in, and given that<br class="gmail_msg">
resurgence lately, I am honestly afraid adding more things will make<br class="gmail_msg">
it worse.<br class="gmail_msg">
<br class="gmail_msg">
A red bot can't catch new errors. A slow red bot can go on red for<br class="gmail_msg">
weeks (and we have seen it numerous times) because once you fix bug<br class="gmail_msg">
#1, #2 has made #3 appear and not be warned.<br class="gmail_msg">
<br class="gmail_msg">
This is not everyone, and I do appreciate all the people that helped<br class="gmail_msg">
us and worried about the breakages, but it's a trend that is<br class="gmail_msg">
increasing, not decreasing. Our team is too small to cope with further<br class="gmail_msg">
increases, so if the community is willing to do its part, I think we<br class="gmail_msg">
can make it work.<br class="gmail_msg">
<br class="gmail_msg">
But it has to be slow and steady.<br class="gmail_msg">
<br class="gmail_msg">
cheers,<br class="gmail_msg">
--renato<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
LLVM Developers mailing list<br class="gmail_msg">
<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="gmail_msg">
</blockquote></div></div>