Renato Golin via llvm-dev
2016-Jul-25 20:25 UTC
[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. 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.> 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
Hal Finkel via llvm-dev
2016-Jul-25 20:33 UTC
[llvm-dev] [RFC] Make Lanai backend non-experimental
----- 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
Philip Reames via llvm-dev
2016-Jul-26 01:58 UTC
[llvm-dev] [RFC] Make Lanai backend non-experimental
> 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