[llvm-dev] [RFC] Lanai backend

[Mehdi Amini via llvm-dev]

> On Feb 9, 2016, at 10:30 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
>> On Feb 9, 2016, at 10:24 PM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> 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).
> 
> Yes, I think this is a reasonable point.  The cheapest SystemZ system is somewhere around $75K, so widespread availability isn’t really a relevant criteria for accepting that.
> 
> Given that, I personally have no objection to accepting the port as an experimental backend.  For it to be a non-experiemental backend, I think it needs to have a buildbot running execution tests for the target.  This can either be a simulator or google could host a buildbot on the hardware they presumably have and make the results public.

Are the existing non-experimental backends passing this bar: NVPTX, AMDGPU, Hexagon (?) , XCore, BPF, MSP430, Sparc ? 
If not why make it a condition for Lanai?


While I'm here, FWIW it's a +1 for me to include it.
As much as I share Pete's point on the fact that it would be the first backend without an actual possible usage (outside of Google?), and the question I would ask would be about the added value compared to having it as a separate repo on GitHub.
I believe (as many others in this thread) that the potential added value (new contributors, image we give of the project, educational purpose, + others that we don't know about yet) makes it a clear net win for the project, and the policy on removing the backend if the maintainers disappear makes it low risk as well. (I still hope the code will be well documented (tablegen file included...), following LLVM coding standards, and will come with nice reduced and documented lit tests, so that maintaining this new backend will be a pleasure for everyone ;-))

-- 
Mehdi