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, > > Hi Jacques, > > > We would like to contribute a new backend for the Lanai processor > > I suppose I can guess from your e-mail address who "we" are? >Yep!> > > (derived from the processor described in [1]). > > Lanai is a simple in-order 32-bit processor with: > > Can you say a few words about what this is, in what hardware it appears, > and how it can be used? Is this the Myricom processor? What version(s)?This is internal hardware for us, so there's not a lot we can share, and you can't really grab a version of the hardware. If that's a problem for the community, I completely understand. Mostly, I wanted to offer to upstream this because it seems likely about the same utility as the AMDGPU backend for folks without an AMDGPU, or the XCore backend, etc. It's small, and we're happy maintaining it and taking on any of the effort around it. We're also happy with the usual policy of if the maintainers stop showing up, the backend goes away. But we're working on the backend a bunch, and it didn't make sense to keep it walled off. Especially if there is anything that can be reused in other backends and/or if there is any common infrastructure we need, this makes it easy to test. Still, totally up to the community if they want this. =] Aside from the Clang/LLVM support, what other software, drivers, etc. would> be needed to make use of this support? What versions of that software? >This is a question for Jacques, I'll let him fill in the details. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/d129f570/attachment.html>
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: > >> ----- 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, >> >> Hi Jacques, >> >> > We would like to contribute a new backend for the Lanai processor >> >> I suppose I can guess from your e-mail address who "we" are? >> > > Yep! > > >> >> > (derived from the processor described in [1]). >> > Lanai is a simple in-order 32-bit processor with: >> >> Can you say a few words about what this is, in what hardware it appears, >> and how it can be used? Is this the Myricom processor? What version(s)? > > > This is internal hardware for us, so there's not a lot we can share, and > you can't really grab a version of the hardware. If that's a problem for > the community, I completely understand. > > Mostly, I wanted to offer to upstream this because it seems likely about > the same utility as the AMDGPU backend for folks without an AMDGPU, or the > XCore backend, etc. It's small, and we're happy maintaining it and taking > on any of the effort around it. We're also happy with the usual policy of > if the maintainers stop showing up, the backend goes away. > > But we're working on the backend a bunch, and it didn't make sense to keep > it walled off. Especially if there is anything that can be reused in other > backends and/or if there is any common infrastructure we need, this makes > it easy to test. > > Still, totally up to the community if they want this. =] > > Aside from the Clang/LLVM support, what other software, drivers, etc. >> would be needed to make use of this support? What versions of that software? >> > > This is a question for Jacques, I'll let him fill in the details. >Aside from Clang/LLVM support the only other software we use are linker support in binutils. We have not submitted those yet but it is based on the previous binutils used (https://github.com/myri/lanai-binutils) but targeting ELF instead of COFF.> > -Chandler >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/6a6770f8/attachment.html>
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: >> >>> ----- 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, >>> >>> Hi Jacques, >>> >>> > We would like to contribute a new backend for the Lanai processor >>> >>> I suppose I can guess from your e-mail address who "we" are? >>> >> >> Yep! >> >> >>> >>> > (derived from the processor described in [1]). >>> > Lanai is a simple in-order 32-bit processor with: >>> >>> Can you say a few words about what this is, in what hardware it appears, >>> and how it can be used? Is this the Myricom processor? What version(s)? >> >> >> This is internal hardware for us, so there's not a lot we can share, and >> you can't really grab a version of the hardware. If that's a problem for >> the community, I completely understand. >> >> Mostly, I wanted to offer to upstream this because it seems likely about >> the same utility as the AMDGPU backend for folks without an AMDGPU, or the >> XCore backend, etc. It's small, and we're happy maintaining it and taking >> on any of the effort around it. We're also happy with the usual policy of >> if the maintainers stop showing up, the backend goes away. >> >> But we're working on the backend a bunch, and it didn't make sense to >> keep it walled off. Especially if there is anything that can be reused in >> other backends and/or if there is any common infrastructure we need, this >> makes it easy to test. >> >> Still, totally up to the community if they want this. =] >> >> Aside from the Clang/LLVM support, what other software, drivers, etc. >>> would be needed to make use of this support? What versions of that software? >>> >> >> This is a question for Jacques, I'll let him fill in the details. >> > > Aside from Clang/LLVM support the only other software we use are linker > support in binutils. We have not submitted those yet but it is based on the > previous binutils used (https://github.com/myri/lanai-binutils) but > targeting ELF instead of COFF. > > >> >> -Chandler >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/bc0c8ef3/attachment.html>
On 9 February 2016 at 18:05, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Mostly, I wanted to offer to upstream this because it seems likely about the > same utility as the AMDGPU backend for folks without an AMDGPU, or the XCore > backend, etc. It's small, and we're happy maintaining it and taking on any > of the effort around it. We're also happy with the usual policy of if the > maintainers stop showing up, the backend goes away.I was going to mention it, but you guys know very well the drill, so unless this hardware changes fundamental parts of the middle end in ways that are unnatural to most other targets (doesn't seem that way), then I see no reason why not have it upstream. However, there are no tests at all on the reviews, and that is a red flag. I was expecting Clang driver tests, code-gen tests, instruction encoding/decoding, ABI and frame lowering tests, etc. Without these, I can't see the benefits of having the target upstream, since I'll have no idea what your target is expected to do when I add/change some generic code generation option. cheers, --renato
On Tue, Feb 9, 2016 at 10:21 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 9 February 2016 at 18:05, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Mostly, I wanted to offer to upstream this because it seems likely about > the > > same utility as the AMDGPU backend for folks without an AMDGPU, or the > XCore > > backend, etc. It's small, and we're happy maintaining it and taking on > any > > of the effort around it. We're also happy with the usual policy of if the > > maintainers stop showing up, the backend goes away. > > I was going to mention it, but you guys know very well the drill, so > unless this hardware changes fundamental parts of the middle end in > ways that are unnatural to most other targets (doesn't seem that way), > then I see no reason why not have it upstream. > > However, there are no tests at all on the reviews, and that is a red > flag. I was expecting Clang driver tests, code-gen tests, instruction > encoding/decoding, ABI and frame lowering tests, etc. Without these, I > can't see the benefits of having the target upstream, since I'll have > no idea what your target is expected to do when I add/change some > generic code generation option. > > cheers, > --renato >I placed all the tests along with the backend in http://reviews.llvm.org/ D17002. I can definitely add some more tests. Best, Jacques -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/ced976d1/attachment.html>
On 02/09/2016 10:05 AM, Chandler Carruth via llvm-dev wrote:> On Tue, Feb 9, 2016 at 9:58 AM Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > ----- Original Message ----- > > From: "Jacques Pienaar via llvm-dev" <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> > > To: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > Sent: Tuesday, February 9, 2016 11:40:21 AM > > Subject: [llvm-dev] [RFC] Lanai backend > > > Hi all, > > Hi Jacques, > > > We would like to contribute a new backend for the Lanai processor > > I suppose I can guess from your e-mail address who "we" are? > > > Yep! > > > > (derived from the processor described in [1]). > > Lanai is a simple in-order 32-bit processor with: > > Can you say a few words about what this is, in what hardware it > appears, and how it can be used? Is this the Myricom processor? > What version(s)? > > > This is internal hardware for us, so there's not a lot we can share, > and you can't really grab a version of the hardware. If that's a > problem for the community, I completely understand. > > Mostly, I wanted to offer to upstream this because it seems likely > about the same utility as the AMDGPU backend for folks without an > AMDGPU, or the XCore backend, etc. It's small, and we're happy > maintaining it and taking on any of the effort around it. We're also > happy with the usual policy of if the maintainers stop showing up, the > backend goes away. > > But we're working on the backend a bunch, and it didn't make sense to > keep it walled off. Especially if there is anything that can be reused > in other backends and/or if there is any common infrastructure we > need, this makes it easy to test. > > Still, totally up to the community if they want this. =]I see no problem with having the backend upstream with the understanding that all the normal policies apply. Getting more people working on ToT is valuable to the community as a whole and provided it's "just another backend" with plenty of tests, the cost is low. Speaking of which, have we ever documented what those policies actually are?> > Aside from the Clang/LLVM support, what other software, drivers, > etc. would be needed to make use of this support? What versions of > that software? > > > This is a question for Jacques, I'll let him fill in the details. > > -Chandler > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/e4806c70/attachment.html>
----- Original Message -----> From: "Philip Reames" <listmail at philipreames.com> > To: "Chandler Carruth" <chandlerc at google.com>, "Hal Finkel" > <hfinkel at anl.gov>, "Jacques Pienaar" <jpienaar at google.com> > Cc: llvm-dev at lists.llvm.org > Sent: Tuesday, February 9, 2016 12:28:20 PM > Subject: Re: [llvm-dev] [RFC] Lanai backend> On 02/09/2016 10:05 AM, Chandler Carruth via llvm-dev wrote:> > 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, > > >> > > Hi Jacques, > > >> > > > We would like to contribute a new backend for the Lanai > > > > processor > > >> > > I suppose I can guess from your e-mail address who "we" are? > > >> > Yep! >> > > > (derived from the processor described in [1]). > > > > > > > Lanai is a simple in-order 32-bit processor with: > > >> > > Can you say a few words about what this is, in what hardware it > > > appears, and how it can be used? Is this the Myricom processor? > > > What > > > version(s)? > > > > > This is internal hardware for us, so there's not a lot we can > > share, > > and you can't really grab a version of the hardware. If that's a > > problem for the community, I completely understand. >> > Mostly, I wanted to offer to upstream this because it seems likely > > about the same utility as the AMDGPU backend for folks without an > > AMDGPU, or the XCore backend, etc. It's small, and we're happy > > maintaining it and taking on any of the effort around it. We're > > also > > happy with the usual policy of if the maintainers stop showing up, > > the backend goes away. >> > But we're working on the backend a bunch, and it didn't make sense > > to > > keep it walled off. Especially if there is anything that can be > > reused in other backends and/or if there is any common > > infrastructure we need, this makes it easy to test. >> > Still, totally up to the community if they want this. =] > > I see no problem with having the backend upstream with the > understanding that all the normal policies apply. Getting more > people working on ToT is valuable to the community as a whole and > provided it's "just another backend" with plenty of tests, the cost > is low.I completely agree.> Speaking of which, have we ever documented what those policies > actually are?I don't believe so. -Hal> > > Aside from the Clang/LLVM support, what other software, drivers, > > > etc. > > > would be needed to make use of this support? What versions of > > > that > > > software? > > >> > This is a question for Jacques, I'll let him fill in the details. >> > -Chandler >> > _______________________________________________ > > > 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