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

[Hal Finkel via llvm-dev]

----- 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.

> 
> 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