similar to: [RFC] Make Lanai backend non-experimental

Do you MC support? Cheers, Rafael On Feb 9, 2016 1:12 PM, "Jacques Pienaar via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Feb 9, 2016 at 10:05 AM, Chandler Carruth <chandlerc at google.com> > wrote: > >> On Tue, Feb 9, 2016 at 9:58 AM Hal Finkel via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>>

The ISA & encoding is documented in the comments and diagrams of lib/Target/Lanai/LanaiInstrFormats.td. If that makes sense I'll add a link to this tablegen in docs/CompilerWriterInfo.rst. Thanks, Jacques On Tue, Feb 9, 2016 at 2:12 PM, Sean Silva <chisophugis at gmail.com> wrote: > Do you have a psABI document? Or an ISA reference? Or an encoding > reference? > > I

On Tue, Feb 9, 2016 at 9:58 AM Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ----- Original Message ----- > > From: "Jacques Pienaar via llvm-dev" <llvm-dev at lists.llvm.org> > > To: llvm-dev at lists.llvm.org > > Sent: Tuesday, February 9, 2016 11:40:21 AM > > Subject: [llvm-dev] [RFC] Lanai backend > > > Hi all, >

> On Jul 19, 2016, at 12:57 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Renato >> On Jul 19, 2016, at 9:42 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> A few basic rules to get accepted are if: >> * the target exists and can be easily purchased / emulated

Hi all, We would like to contribute a new backend for the Lanai processor (derived from the processor described in [1]). Lanai is a simple in-order 32-bit processor with: * 32 32-bit registers, including: * 2 registers with fixed values; * 4 used for program state tracking (PC, SP, FP, RCA); * 2 reserved for explicit usage by user (R10 and R11), used in threading library; * Up

On Tue, Feb 9, 2016 at 2:37 PM, Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Feb 9, 2016, at 9:40 AM, Jacques Pienaar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We would like to contribute a new backend for the Lanai processor > (derived from the processor described in [1]). > >

On 7/19/2016 6:12 AM, Renato Golin via llvm-dev wrote: > > I don't see why not. LGTM. Same here. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On 26 July 2016 at 00:08, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It is unquestionably easier for a contributor to land their backend in-tree > than to maintain it out-of-tree. This is because landing it in tree shifts > the maintenance burden from the *contributor* to the *community*. If there > is low value to the community, then this is a "bad

On Mon, Jul 25, 2016 at 11:46 AM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Jul 19, 2016 at 9:42 AM Renato Golin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 19 July 2016 at 17:04, Martin J. O'Riordan via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > Presumably if my out-of-tree backend

On 19 July 2016 at 17:04, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Presumably if my out-of-tree backend was to be pushed to LLVM, it too would be considered experimental. Yes. Though, not all out-of-tree back-ends end up upstream for different reasons. A few basic rules to get accepted are if: * the target exists and can be easily purchased / emulated

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

----- Original Message ----- > From: "Renato Golin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rafael Espíndola" <rafael.espindola at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, February 10, 2016 7:50:33 AM > Subject: Re: [llvm-dev] [RFC] Lanai backend > > On 10 February 2016 at 13:42,

Hey, I'm playing around with a backend with no callee saved registers and noticed more spilling than seems needed. I tried digging into the spilling code but with limited success. I also tried removing all the callee saved registers in the X86 backend and saw the same effect (basically making CSRs equal to CSR_NoRegs). So I seem to be misunderstanding something or missing something simple,

> Yes, I think this is a reasonable point. The cheapest SystemZ system is somewhere around $75K, so widespread availability isn’t really a relevant criteria for accepting that. And SystemZ is hopefully a good comparison in that is a new and well isolated backend. Ever since it went in I can remember only ever discussing 1 or 2 patches, and the last case pushed me to improving common code

----- Original Message ----- > From: "Pete Cooper via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Sean Silva" <chisophugis at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, February 9, 2016 10:59:58 PM > Subject: Re: [llvm-dev] [RFC] Lanai backend > > > Hi Sean > > > I think you’ve

On 26 August 2016 at 17:45, Mehdi Amini <mehdi.amini at apple.com> wrote: > “Major corporation” does not mean size to me, I read it as “having a major involvement in the project”. Still, you're rejecting new developers because they haven't contributed much before. But if their back-end is upstream, than they'll contribute code upstream for their changes on their back-end.

On 02/09/2016 08:59 PM, Pete Cooper via llvm-dev wrote: > Hi Sean > > I think you’ve summed it up really well here. > > Personally I don’t think we should accept backends for which there is > no way to run the code. The burden (however small) on the community > to having an in-tree backend they can’t use is too high IMO. > > As you point out ‘no way to run the code’

On Tue, Feb 9, 2016 at 11:01 PM, Pete Cooper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Feb 9, 2016, at 10:24 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > You've raised an important point here Pete, and while I disagree pretty > strongly with it (regardless of whether Lanai makes sense or not), I'm glad > that you've

Re-reading the thread, it looks like there is a difference of opinion what "an active community behind the target" means: an active community of LLVM-target-maintainers, and/or an active community of end-users. I'd think the immediate practical concern is that there is an active community of LLVM-target-maintainers, so that the maintenance burden does not fall unduly on the rest of

You've raised an important point here Pete, and while I disagree pretty strongly with it (regardless of whether Lanai makes sense or not), I'm glad that you've surfaced it where we can clearly look at the issue. The idea of "it really should have users outside of just the people who have access to the HW" I think is deeply problematic for the project as a whole. Where does