You’ve raised an important point here Pete, and while I disagree pretty strongly with it (regardless of whether Lanai makes sense or not), I’m glad that you’ve surfaced it where we can clearly look at the issue.
The idea of “it really should have users outside of just the people who have access to the HW” I think is deeply problematic for the project as a whole. Where does it stop?
While I may have the theoretical ability to get access to an AVR, Hexagon, MSP430, SystemZ, or XCore processor… It is a practical impossibility. There is no way that I, or I suspect 95% of LLVM contributors, will be able to run code for all these platforms. And for some of them, I suspect it is already the case that their only users have access to specialized, quite hard to acquire hardware (both Hexagon[1] and SystemZ come to mind).
But I really don’t think we want to kick any of these backends out of LLVM, or that they were a mistake to include in the first place. So the question really is whether the lack of theoretical access matters substantially more than lack of practical access.
This policy would also set an extremely alarming precedent to me at least, maybe one that you’re not even intending: what’s the difference between hardware and an operating system? I don’t think we want to limit the operating system support of Clang to those which are readily accessible. Lots of folks don’t have a practical ability to use Apple’s operating system because they don’t own any of Apple’s hardware. And the reverse is of course true – I think if you work at Apple and only own Apple hardware, you probably shoudn’t be expected to boot Windows or Linux and debug something.
We have a growing history of support diverse platforms, both hardware and software. And when we do this, we rely on the community contributors who care deeply about those platforms to bridge the gap and support those developers who don’t have ready access to the platform. I don’t want to see this change, as I think it has been absolutely critical to the community growing and thriving over the past few years. My best memory of this is with AMDGPU (which is why I brought it up, I agree with others that MSP430 or XCore are perhaps better examples here). I was making a change to a DAG combine of some form and it ended up regressing the AMDGPU (R600 at the time) regression tests. I was completely lost. While in theory, I could go pick up such a GPU and install it in a machine to test things out, in practice I’m never going to do that. If that were the requirement, I would just have to abandon such changes. But instead, Tom and Matt bent over backwards to help me out, looked at all the test case updates I sent them and helped verify that indeed, the changes were harmless or even helpful. I didn’t need hardware, an emulator, or even an ISA spec. And I think this is awesome.
So regardless of what we do with Lanai, I feel really strongly that we don’t want to use “have other users” or “can run the code” as the bar for supporting platforms.
But all that really doesn’t mean we should necessarily adopt Lanai. I think this is probably the nearest tradeoff the community has looked at (that’s actually one reason I worked internally to see if we could contribute the backend). And it is definitely is a tradeoff.
IMO, it is worth the tradeoff, just like it was for BPF, AMDGPU, and others. Our goal should be to get more upstream contributors and LLVM developers, and to the extent that we can do that by encouraging people working on new (to the community) platforms, whether software or hardware, to work on them upstream and in-tree, I think we should.
Personally, I’m not concerned about how encumbered in any sense SystemZ is or isn’t (I have no idea about such things). I don’t care that I’m completely unlikely to be able to get a SystemZ system, or even an emulator. I’m probably not going to spend a whole lot of time trying to read the entire ISA spec. To me, while those things would help motivate the issue, they’re not the operative factor in my decision. Instead, the fact that IBM contributed SystemZ, maintained it, and was able to do more work in-tree was justification enough.
My 2 cents, sorry I took so many words to express them. =]
-Chandler
[1] Yes, I know Hexagon chips are present all over Android devices, but I have no idea how one would go about actually programming most of them. Maybe it’s actually much easier than I imagine, if so, apologize. My impression has just been that Qualcomm (the producer of the Hexagon chips) is by far the largest user of the backend if not the exclusive user. None of this is a criticism of course! =]
