----- Original Message -----> From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>, "Mehdi Amini" <mehdi.amini at apple.com> > Sent: Tuesday, July 26, 2016 2:16:51 PM > Subject: Re: [llvm-dev] Target Acceptance Policy > > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote: > > I think there are different kinds of inflexibility. We will use our > > collective professional judgment. There are some large-scale > > design changes that we might decide can happen over time. Whatever > > we decide to accept, however, needs to be in good shape for what > > it is and follow our coding conventions. > > Absolutely. There is a large range of solutions, and we have been > most > successful on the ones we picked over the years. I think we should > continue with the trend. > > What (I think) I have proposed is nothing different than what we've > been doing (ie. I'm not trying to change the status quo).Sure; have we accepted backends in the recent past which contained code that did not meet our coding conventions? -Hal> > So, if that's not what's coming out, my wording is wrong, please > advise. If it is, than I don't think we should argue *now*. > > I just want to encode what is, and then, once we have something in, > working and actively helping people add their targets, we can discuss > (in separate) the merits of our current policies. > > Maybe I should have said that from the beginning. Oh well, hind sight > and all. > > --renato >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On 27 Jul 2016 12:50 a.m., "Hal Finkel" <hfinkel at anl.gov> wrote:> Sure; have we accepted backends in the recent past which contained codethat did not meet our coding conventions? I'm no authority, but when people have a back end to contribute, they have already done some due diligence, and the conventions are usually mostly there. But because the target was implemented off tree, there was less peer review, and why we may accept some minor violations if they get fixed later. Usually things that clang format can't fix. For more accurate information, you could look into the recent merges: bpf, system z, apple's ARM64, lanai. They all had different histories. Also arm's AArch64, which was mostly brewed inside tree, but a good part was copied from the arm back end (I even found the same bugs on both) ;) I personally see all those efforts as successful, each with their own quirks, maybe none of them perfect, but definitely better with them than without. Maybe I'm being too optimistic? Cheers, Renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160727/833de061/attachment.html>
----- Original Message -----> From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, July 26, 2016 7:11:29 PM > Subject: Re: [llvm-dev] Target Acceptance Policy > > On 27 Jul 2016 12:50 a.m., "Hal Finkel" < hfinkel at anl.gov > wrote: > > Sure; have we accepted backends in the recent past which contained > > code that did not meet our coding conventions? > > I'm no authority, but when people have a back end to contribute, they > have already done some due diligence, and the conventions are > usually mostly there. > > But because the target was implemented off tree, there was less peer > review, and why we may accept some minor violations if they get > fixed later. Usually things that clang format can't fix.Like what? Minor things are generally things that are easy to ask to be changed in a code review.> > For more accurate information, you could look into the recent merges: > bpf, system z, apple's ARM64, lanai. They all had different > histories. Also arm's AArch64, which was mostly brewed inside tree, > but a good part was copied from the arm back end (I even found the > same bugs on both) ;) > > I personally see all those efforts as successful, each with their own > quirks, maybe none of them perfect, but definitely better with them > than without.I agree. -Hal> > Maybe I'm being too optimistic? > > Cheers, > Renato >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory