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 to 4 used for argument passing;
* No callee-saved registers
* No floating point support
Backend development is focused primarily on compiling C99 code (no
exception support). The patches implement all the parts required for code
generation:
* LLVM triple: http://reviews.llvm.org/D17003
* Clang support: http://reviews.llvm.org/D17002
* MCExpr & ELF: http://reviews.llvm.org/D17008
* Lanai backend (lib/Target/Lanai): http://reviews.llvm.org/D17011
We are still actively developing the backend and have many optimizations in
mind.
I'll be the maintainer of this backend.
Please leave code comments on the Phab patches, while discussing high-level
comments about the backend on this llvm-dev thread.
Thanks,
Jacques
[1] David E. Culler, Anoop Gupta, and Jaswinder Pal Singh. 1997. Parallel
Computer Architecture: A Hardware/Software Approach (1st ed.). Morgan
Kaufmann Publishers Inc., San Francisco, CA, USA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/1ca93505/attachment.html>
----- 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 processorI suppose I can guess from your e-mail address who "we" are?> (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)? 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? -Hal> * 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 to 4 used for argument passing; > * No callee-saved registers > * No floating point support> Backend development is focused primarily on compiling C99 code (no > exception support). The patches implement all the parts required for > code generation:> * LLVM triple: http://reviews.llvm.org/D17003 > * Clang support: http://reviews.llvm.org/D17002 > * MCExpr & ELF: http://reviews.llvm.org/D17008 > * Lanai backend (lib/Target/Lanai): http://reviews.llvm.org/D17011> We are still actively developing the backend and have many > optimizations in mind.> I'll be the maintainer of this backend.> Please leave code comments on the Phab patches, while discussing > high-level comments about the backend on this llvm-dev thread.> Thanks,> Jacques> [1] David E. Culler, Anoop Gupta, and Jaswinder Pal Singh. 1997. > Parallel Computer Architecture: A Hardware/Software Approach (1st > ed.). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. > _______________________________________________ > 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
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>
Do you have a psABI document? Or an ISA reference? Or an encoding reference? I know at least the encoding reference is missing for AArch64, so it's not a huge deal, but anything we can put in http://llvm.org/docs/CompilerWriterInfo.html (docs/CompilerWriterInfo.rst) would be appreciated. -- Sean Silva On Tue, 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]). > > 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 to 4 used for argument passing; > * No callee-saved registers > * No floating point support > > Backend development is focused primarily on compiling C99 code (no > exception support). The patches implement all the parts required for code > generation: > > * LLVM triple: http://reviews.llvm.org/D17003 > * Clang support: http://reviews.llvm.org/D17002 > * MCExpr & ELF: http://reviews.llvm.org/D17008 > * Lanai backend (lib/Target/Lanai): http://reviews.llvm.org/D17011 > > We are still actively developing the backend and have many optimizations > in mind. > > I'll be the maintainer of this backend. > > Please leave code comments on the Phab patches, while discussing > high-level comments about the backend on this llvm-dev thread. > > Thanks, > > Jacques > > [1] David E. Culler, Anoop Gupta, and Jaswinder Pal Singh. 1997. Parallel > Computer Architecture: A Hardware/Software Approach (1st ed.). Morgan > Kaufmann Publishers Inc., San Francisco, CA, USA. > > _______________________________________________ > 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/b0b8407d/attachment.html>
On 9 February 2016 at 14:12, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I know at least the encoding reference is missing for AArch64,I added it in a while back. The "Architecture Reference Manual" contains all that info. Perhaps I should reword it to make that clearer for anyone coming along later. Tim.
> 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]).Hi Jacques, We generally have a low bar for accepting new “experimental” backends, but I think that this is the first proposal to add a target for a hardware that general LLVM contributors can’t have access to. As such, we’ll have to figure out as a community whether this makes sense. Here are the tradeoffs I see of accepting the backend: 1) I imagine that there is a big win for you, not having to merge with mainline. Maintaining an out of tree backend is a pain :-) 2) For the community, this is probably a net loss since changes to common codegen could would be required to update your backend, but no one else in the community would benefit from the target being in mainline. 3) There is probably a small but non-zero benefit to keeping your team working directly on mainline, since you’re more likely to do ancillary work in ToT. If your development is in mainline, this work is most likely to go into llvm.org instead of into your local branch. 4) There could be an educational benefit of having the backend, particularly if it has unique challenges to overcome. What do others think about this? I know that several organizations have not even bothered proposing internal-only targets for inclusion in llvm.org, since they would effectively be contributing dead code that the community would have to maintain. -Chris
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 know at least the encoding reference is missing for AArch64, so it's not > a huge deal, but anything we can put in http://llvm.org/docs/ > CompilerWriterInfo.html (docs/CompilerWriterInfo.rst) would be > appreciated. > > -- Sean Silva > > On Tue, 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]). >> >> 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 to 4 used for argument passing; >> * No callee-saved registers >> * No floating point support >> >> Backend development is focused primarily on compiling C99 code (no >> exception support). The patches implement all the parts required for code >> generation: >> >> * LLVM triple: http://reviews.llvm.org/D17003 >> * Clang support: http://reviews.llvm.org/D17002 >> * MCExpr & ELF: http://reviews.llvm.org/D17008 >> * Lanai backend (lib/Target/Lanai): http://reviews.llvm.org/D17011 >> >> We are still actively developing the backend and have many optimizations >> in mind. >> >> I'll be the maintainer of this backend. >> >> Please leave code comments on the Phab patches, while discussing >> high-level comments about the backend on this llvm-dev thread. >> >> Thanks, >> >> Jacques >> >> [1] David E. Culler, Anoop Gupta, and Jaswinder Pal Singh. 1997. Parallel >> Computer Architecture: A Hardware/Software Approach (1st ed.). Morgan >> Kaufmann Publishers Inc., San Francisco, CA, USA. >> >> _______________________________________________ >> 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/45164364/attachment.html>
My random view: If the team is going to contribute more generally (IE do more than maintain the backend), it could be a net win for the community. Otherwise, ... 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]). > > Hi Jacques, > > We generally have a low bar for accepting new “experimental” backends, but > I think that this is the first proposal to add a target for a hardware that > general LLVM contributors can’t have access to. As such, we’ll have to > figure out as a community whether this makes sense. > > Here are the tradeoffs I see of accepting the backend: > > 1) I imagine that there is a big win for you, not having to merge with > mainline. Maintaining an out of tree backend is a pain :-) > > 2) For the community, this is probably a net loss since changes to common > codegen could would be required to update your backend, but no one else in > the community would benefit from the target being in mainline. > > 3) There is probably a small but non-zero benefit to keeping your team > working directly on mainline, since you’re more likely to do ancillary work > in ToT. If your development is in mainline, this work is most likely to go > into llvm.org instead of into your local branch. > > 4) There could be an educational benefit of having the backend, > particularly if it has unique challenges to overcome. > > > What do others think about this? I know that several organizations have > not even bothered proposing internal-only targets for inclusion in > llvm.org, since they would effectively be contributing dead code that the > community would have to maintain. > > -Chris > _______________________________________________ > 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/9041fa84/attachment-0001.html>
It'd be be super-exciting if everyone working on random LLVM backends pushed their targets upstream, and then did their development on ToT! If this proposal would catalyze other organizations to submit their backends upstream as well, that would seem like a huge win. I'd expect the benefit of having developers of such targets all working upstream to very much outweigh the usually minor cost of updating it for other codegen changes. That only holds as long as there *is* an active maintainer, of course. If a target actually becomes deadweight, it should be removed as soon as possible. On Tue, Feb 9, 2016 at 5: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]). > > Hi Jacques, > > We generally have a low bar for accepting new “experimental” backends, but > I think that this is the first proposal to add a target for a hardware that > general LLVM contributors can’t have access to. As such, we’ll have to > figure out as a community whether this makes sense. > > Here are the tradeoffs I see of accepting the backend: > > 1) I imagine that there is a big win for you, not having to merge with > mainline. Maintaining an out of tree backend is a pain :-) > > 2) For the community, this is probably a net loss since changes to common > codegen could would be required to update your backend, but no one else in > the community would benefit from the target being in mainline. > > 3) There is probably a small but non-zero benefit to keeping your team > working directly on mainline, since you’re more likely to do ancillary work > in ToT. If your development is in mainline, this work is most likely to go > into llvm.org instead of into your local branch. > > 4) There could be an educational benefit of having the backend, > particularly if it has unique challenges to overcome. > > > What do others think about this? I know that several organizations have > not even bothered proposing internal-only targets for inclusion in > llvm.org, since they would effectively be contributing dead code that the > community would have to maintain. > > -Chris > _______________________________________________ > 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/98885b06/attachment.html>
----- Original Message -----> From: "Chris Lattner via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Jacques Pienaar" <jpienaar at google.com> > Cc: llvm-dev at lists.llvm.org > Sent: Tuesday, February 9, 2016 4:37:18 PM > Subject: Re: [llvm-dev] [RFC] Lanai backend > > > > 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]). > > Hi Jacques, > > We generally have a low bar for accepting new “experimental” > backends, but I think that this is the first proposal to add a > target for a hardware that general LLVM contributors can’t have > access to. As such, we’ll have to figure out as a community whether > this makes sense. > > Here are the tradeoffs I see of accepting the backend: > > 1) I imagine that there is a big win for you, not having to merge > with mainline. Maintaining an out of tree backend is a pain :-) > > 2) For the community, this is probably a net loss since changes to > common codegen could would be required to update your backend, but > no one else in the community would benefit from the target being in > mainline.In my experience, updating backend code to deal with API changes, etc. is a much smaller problem than trying to update updating regression tests to account for changes in common code. As a result, making sure that the regression tests are well written (use regular expressions instead of hard-coded register numbers, CHECK-DAG, etc. where appropriate), and documented to make clear what is being tested is very important. That having been said, the regression tests are, in a sense, the most valuable contribution a backend like this makes. They'll test the common codegen code in configurations not hit by the other backends (yet!), and the more of that the better. Plus, the more regression tests we have, the better self hosting becomes as a test on all targets ;)> > 3) There is probably a small but non-zero benefit to keeping your > team working directly on mainline, since you’re more likely to do > ancillary work in ToT. If your development is in mainline, this > work is most likely to go into llvm.org instead of into your local > branch.This really depends on the development philosophy adopted by the backend maintainers. If code that *should* be common code is put up for review and properly integrated into the common infrastructure, then it can be a big win. I've not yet met a backend for real hardware that did not require at least some common codegen enhancement to function well, and these enhancements often end up helping at least some other targets. If, on the other hand, deficiencies in the common codegen are just hacked around in the backend, or enhancements otherwise live only there, the value to the community will be much smaller. At this point, I trust Google to do the right thing here. -Hal> > 4) There could be an educational benefit of having the backend, > particularly if it has unique challenges to overcome. > > > What do others think about this? I know that several organizations > have not even bothered proposing internal-only targets for inclusion > in llvm.org, since they would effectively be contributing dead code > that the community would have to maintain. > > -Chris > _______________________________________________ > 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
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]). > > Hi Jacques, > > We generally have a low bar for accepting new “experimental” backends, but > I think that this is the first proposal to add a target for a hardware that > general LLVM contributors can’t have access to. As such, we’ll have to > figure out as a community whether this makes sense. > > Here are the tradeoffs I see of accepting the backend: > > 1) I imagine that there is a big win for you, not having to merge with > mainline. Maintaining an out of tree backend is a pain :-) > > 2) For the community, this is probably a net loss since changes to common > codegen could would be required to update your backend, but no one else in > the community would benefit from the target being in mainline. > > 3) There is probably a small but non-zero benefit to keeping your team > working directly on mainline, since you’re more likely to do ancillary work > in ToT. If your development is in mainline, this work is most likely to go > into llvm.org instead of into your local branch. > > 4) There could be an educational benefit of having the backend, > particularly if it has unique challenges to overcome. > > > What do others think about this? I know that several organizations have > not even bothered proposing internal-only targets for inclusion in > llvm.org, since they would effectively be contributing dead code that the > community would have to maintain. >One data point (IIRC) is that the NVPTX backend sat in tree for a long time without a way to actually use them. But lately this has been opening up (e.g. http://llvm.org/docs/CompileCudaWithLLVM.html). However, the obstacle for NVPTX was mostly a software proprietary-ness (no way to plug it into the driver stack really, except via nvidia's own proprietary software), whereas the actual hardware was available. For the Lanai stuff, it seems like the hardware is fundamentally not available for purchase. The reverse situation is with e.g. Apple's GPU backends, where the devices are readily available, but (AFAIK) even if the backend were open-source you couldn't run the code produced by the open-source compiler. Or to put it in matrix form (this is all heavily prefixed by "AFAIK"; corrections welcome): AMDGPU: InTree:Yes DevicesAvailable:Yes CanIRunTheCode:Yes NVPTX: InTree:Yes DevicesAvailable:Yes CanIRunTheCode:Yes Lanai: InTree:? DevicesAvailable:No CanIRunTheCode:No Apple GPU's: InTree:No DevicesAvailable:Yes CanIRunTheCode:No I couldn't come up with a good name for "Can I Run The Code" column. Basically it means: "assuming the backend were in open source, could I actually run the code produced by the open source backend somehow?". I had a quick look at lib/Target and it seems like every backend we have has "CanIRunTheCode:Yes" in theory. IIRC, the NVPTX stuff used to actually be "No" though? Anyway, just a random thought. Not sure what the conclusion is. -- Sean Silva> -Chris > _______________________________________________ > 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/ee1df43b/attachment.html>