[llvm-dev] [RFC] Make Lanai backend non-experimental
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 25 18:58:08 PDT 2016
> 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
>> 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
>>> 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
>>> involvement makes the availability of hardware/emulator "nice to
>>> have" but
>>> not essential, and it makes the ISA documentation substantially
>> 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
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev