[llvm-dev] [RFC] Make Lanai backend non-experimental

[Philip Reames via llvm-dev]

> On Jul 25, 2016, at 1:33 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> ----- Original Message -----
>> From: "Renato Golin via llvm-dev" <llvm-dev at lists.llvm.org>
>> To: "Chandler Carruth" <chandlerc at google.com>
>> Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>
>> Sent: Monday, July 25, 2016 3:25:40 PM
>> Subject: Re: [llvm-dev] [RFC] Make Lanai backend non-experimental
>> 
>> Hi Chandler,
>> 
>> I think you have good points. Maybe we could make some hard-lined
>> rules and others as "nice-to-have".
>> 
>> The biggest problem is the community behind it, outside of LLVM. If
>> the community is strong, and they care about LLVM support, than we
>> can
>> keep their back-ends in tree and not have to worry about them.
>> 
>> IIRC, our *only* rule for a long time has been "keep up or give up".
>> Now, how do we know when a target is good for moving out of
>> experimental? And what is the meaning of experimental anyway?
>> 
>> Maybe we should separate the discussion from the actual change. So,
>> if
>> you could comment on the review D22753 about which of the points
>> you'd
>> consider mandatory and which are nice-to-have, that'd probably be
>> easiest.
>> 
>> About the Lanai back-end being official, I have no reservations. But
>> I
>> was the only one to say anything, so I'll wait for others to have
>> their say on the review before I put my approval.
> 
> It's been actively maintained, and does not seem to have caused any particular difficulties for the rest of us. It is fine by me too.
Same here.  

Philip

> 
>> 
>> Just a few unrelated comments below... :)
>> 
>> 
>> On 25 July 2016 at 19:46, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>> Even for fairly pedestrian backends such as AArch64 and PowerPC, we
>>> routinely have people ask active developers on those backends to do
>>> the
>>> triaging of issues.
>> 
>> I think that's most for specific environment than anything else.
>> 
>> Really, you can get sub-$100 AArch64 1-day delivery and a *very*
>> decent open source emulator (QEMU), both system and user level.
> 
> I see your point, but there can also be substantial overhead in person-hours (often which far exceeds the actual hardware costs). Especially for embedded/emulated systems, the turn-around time on builds can be really long. Setting up software environments on these systems can also be time consuming. Learning about the hardware can take a long time.
> 
> -Hal
> 
>> 
>>> And I don't think any of these backends are bad or should be
>>> removed. I
>>> rather like several of them. =] I just think that sufficient
>>> community
>>> involvement makes the availability of hardware/emulator "nice to
>>> have" but
>>> not essential, and it makes the ISA documentation substantially
>>> less
>>> important.
>> 
>> I also don't think emulators replace the ISA in any way, but I get
>> what you mean. Being nice-to-have, either one would be better than
>> nothing, but having both would be really optimal.
>> 
>> Between the two, I'd personally prefer the ISA (if it was correct and
>> complete) than a simulator. But that's me.
>> 
>> cheers,
>> --renato
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev