[llvm-dev] [RFC] Make Lanai backend non-experimental
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 25 13:33:20 PDT 2016
----- 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
> 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,
> you could comment on the review D22753 about which of the points
> consider mandatory and which are nice-to-have, that'd probably be
> About the Lanai back-end being official, I have no reservations. But
> 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>
> > 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.
> > 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev