Hi all, We wish to submit our latest AAP implementation as an experimental backend into LLVM. We need community feedback and reviewers for patches which we will submit soon. AAP was designed in early 2015 and aims to advance compiler development for small deeply embedded Harvard architectures, which are widely used commercially. AAP is freely available as an open source softcore for use in FPGA designs. AAP has wide exposure: at ORCONF16 at CERN, at FOSDEM and at BCS and OSHUG meetings. It is also of commercial interest, because of the potential benefits of providing upstream LLVM support for features found in small embedded processors. Currently there is a complete Clang and LLVM toolchain including gdb, ld and binutils, as well as two simulator implementations. The toolchain is passing all LLVM regression tests and a decent proportion of GCC regression tests. We are also working on a GCC port to allow comparison between compilers, which should be beneficial to both projects. We believe the code base is sufficiently mature that it is appropriate for inclusion. Currently, the full source for AAP can be found on Github: https://github.com/embecosm Details about the ISA, and the hardware implementation can be found on our website: http://www.embecosm.com/resources/appnotes/#EAN13 http://www.embecosm.com/resources/appnotes/#EAN14 We are also planning to talk about AAP at the LLVM Cauldron in Hebden Bridge. We look forward to discussing our work on AAP with those who are attending. Thank you, Ed Jones
On 18 August 2016 at 08:34, Ed Jones via llvm-dev <llvm-dev at lists.llvm.org> wrote:> We believe the code base is sufficiently mature that it is appropriate > for inclusion. Currently, the full source for AAP can be found on Github: > https://github.com/embecosmHi Ed, I had a look at the GitHub project and it wasn't clear what is needed to move the AAP target in-tree. First, it seems you're merging our tree into yours, which means the merge commit [1,2] show the differences between old and new LLVM stuff, not yours vs. upstream. This makes it hard to predict the affected changes. Also, you seem to have a standard-looking lib/Target/AAP [3], which is a good step forward, but you also have added the simulator [4] in there, which is not the right place. This should probably be a different project altogether. So, from our recent check-list for new targets, I'm assuming a few things: Code owner: You? Community: Embecosm + its users License: AFAICS, check. Docs / Impl: check The thing that isn't clear right now is "compatible code and policies". I don't see why we shouldn't take the AAP target, unless it poses a big enough change to IR, the middle end, etc. So, I recommend two steps: 1. A quick summary of the target independent changes you had to do to make your back-end work. Changes to IR semantics, additional Clang checks, base classes overwritten, etc. 2. Propose some patches on Phabricator, showing those differences. These patches don't need to be the whole thing, for now, but basic support ("hello world" style) should be working and tested. We can continue from there. cheers, --renato [1] https://github.com/embecosm/aap-llvm/commit/1d767ab10d0de413c341fe69ca228b97e7e1d255 [2] https://github.com/embecosm/aap-clang/commit/d1c2e5081a6222f2b4ab8d175fbd68a5e803c6d9 [3] https://github.com/embecosm/aap-llvm/tree/aap-master/lib/Target/AAP [4] https://github.com/embecosm/aap-llvm/tree/aap-master/lib/Target/AAPSimulator
Hi Renato, Currently I am building a set of patches which will add AAP piece-wise. I'm following the approach that AVR (and now RISC-V), and the patches I plan on adding are as follows: * Target triple * ELF definition * Basic skeleton with the required build system changes (targetinfo + target machine) * Instruction + Register tablegen * MC layer support * AsmParser * InstPrinter * Disassembler * Bulk of the implementation for lowering, isel and similar At the moment there are only two changes to generic code, one is to override the size of pointers when printing assembly (for AAP we use larger pointer as the upper bits are used for flags), the other is to track live outs of a function (We have some registers which are callee saved, but also used for return values). I'm going to extract these changes into separate patches and submit them along with the above. We're not planning on submitting the simulator yet, we have been keeping it outside of our main Target directory so that we don't write anything that unintentionally relies on the simulator or lets parts of it leak into any patches we submit. We may submit it separately at a later point, as part of the AAP target directory. I imagine either I or my colleague Simon Cook would be the code owner (or both if that's possible). The community is Embecosm, and those who may wish to use AAP as a basis for their work. I will have a few basic patches submitted by the end of the day. Thank you, Ed Jones On 18/08/16 12:22, Renato Golin wrote:> On 18 August 2016 at 08:34, Ed Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We believe the code base is sufficiently mature that it is appropriate >> for inclusion. Currently, the full source for AAP can be found on Github: >> https://github.com/embecosm > > Hi Ed, > > I had a look at the GitHub project and it wasn't clear what is needed > to move the AAP target in-tree. > > First, it seems you're merging our tree into yours, which means the > merge commit [1,2] show the differences between old and new LLVM > stuff, not yours vs. upstream. This makes it hard to predict the > affected changes. > > Also, you seem to have a standard-looking lib/Target/AAP [3], which is > a good step forward, but you also have added the simulator [4] in > there, which is not the right place. This should probably be a > different project altogether. > > So, from our recent check-list for new targets, I'm assuming a few things: > > Code owner: You? > Community: Embecosm + its users > License: AFAICS, check. > Docs / Impl: check > > The thing that isn't clear right now is "compatible code and policies". > > I don't see why we shouldn't take the AAP target, unless it poses a > big enough change to IR, the middle end, etc. So, I recommend two > steps: > > 1. A quick summary of the target independent changes you had to do to > make your back-end work. Changes to IR semantics, additional Clang > checks, base classes overwritten, etc. > > 2. Propose some patches on Phabricator, showing those differences. > These patches don't need to be the whole thing, for now, but basic > support ("hello world" style) should be working and tested. > > We can continue from there. > > cheers, > --renato > > > [1] https://github.com/embecosm/aap-llvm/commit/1d767ab10d0de413c341fe69ca228b97e7e1d255 > [2] https://github.com/embecosm/aap-clang/commit/d1c2e5081a6222f2b4ab8d175fbd68a5e803c6d9 > [3] https://github.com/embecosm/aap-llvm/tree/aap-master/lib/Target/AAP > [4] https://github.com/embecosm/aap-llvm/tree/aap-master/lib/Target/AAPSimulator >
> On Aug 18, 2016, at 4:22 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 18 August 2016 at 08:34, Ed Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We believe the code base is sufficiently mature that it is appropriate >> for inclusion. Currently, the full source for AAP can be found on Github: >> https://github.com/embecosm > > Hi Ed, > > I had a look at the GitHub project and it wasn't clear what is needed > to move the AAP target in-tree. > > First, it seems you're merging our tree into yours, which means the > merge commit [1,2] show the differences between old and new LLVM > stuff, not yours vs. upstream. This makes it hard to predict the > affected changes.Github makes it quite easy I think: https://github.com/embecosm/aap-llvm/compare/3951c48624d73169b5409c490999fadbdafd9fa4...1d767ab10d0de413c341fe69ca228b97e7e1d255 <https://github.com/embecosm/aap-llvm/compare/3951c48624d73169b5409c490999fadbdafd9fa4...1d767ab10d0de413c341fe69ca228b97e7e1d255> — Mehdi> > Also, you seem to have a standard-looking lib/Target/AAP [3], which is > a good step forward, but you also have added the simulator [4] in > there, which is not the right place. This should probably be a > different project altogether. > > So, from our recent check-list for new targets, I'm assuming a few things: > > Code owner: You? > Community: Embecosm + its users > License: AFAICS, check. > Docs / Impl: check > > The thing that isn't clear right now is "compatible code and policies". > > I don't see why we shouldn't take the AAP target, unless it poses a > big enough change to IR, the middle end, etc. So, I recommend two > steps: > > 1. A quick summary of the target independent changes you had to do to > make your back-end work. Changes to IR semantics, additional Clang > checks, base classes overwritten, etc. > > 2. Propose some patches on Phabricator, showing those differences. > These patches don't need to be the whole thing, for now, but basic > support ("hello world" style) should be working and tested. > > We can continue from there. > > cheers, > --renato > > > [1] https://github.com/embecosm/aap-llvm/commit/1d767ab10d0de413c341fe69ca228b97e7e1d255 > [2] https://github.com/embecosm/aap-clang/commit/d1c2e5081a6222f2b4ab8d175fbd68a5e803c6d9 > [3] https://github.com/embecosm/aap-llvm/tree/aap-master/lib/Target/AAP > [4] https://github.com/embecosm/aap-llvm/tree/aap-master/lib/Target/AAPSimulator > _______________________________________________ > 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/20160818/f97eb8fc/attachment.html>
I don't think we've ever really built up clear guidance on this, but I think there needs to be a clear determination that a given target has enough active users to make the maintenance burden worth putting into the mainline. In the past, the only exception I can think of is the Lanai backend, but in that case we have a strong commitment of multiple employees at a major corporation committed to that target's maintenance. So, concretely, can you quantify the active customers for this target? Alex On Aug 18, 2016, at 12:34 AM, Ed Jones via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hi all, > > We wish to submit our latest AAP implementation as an experimental > backend into LLVM. We need community feedback and reviewers for patches > which we will submit soon. > > AAP was designed in early 2015 and aims to advance compiler development > for small deeply embedded Harvard architectures, which are widely used > commercially. AAP is freely available as an open source softcore for use > in FPGA designs. > > AAP has wide exposure: at ORCONF16 at CERN, at FOSDEM and at BCS and > OSHUG meetings. It is also of commercial interest, because of the > potential benefits of providing upstream LLVM support for features found > in small embedded processors. > > Currently there is a complete Clang and LLVM toolchain including gdb, ld > and binutils, as well as two simulator implementations. The toolchain is > passing all LLVM regression tests and a decent proportion of GCC > regression tests. We are also working on a GCC port to allow comparison > between compilers, which should be beneficial to both projects. > > We believe the code base is sufficiently mature that it is appropriate > for inclusion. Currently, the full source for AAP can be found on Github: > https://github.com/embecosm > > Details about the ISA, and the hardware implementation can be found on > our website: > http://www.embecosm.com/resources/appnotes/#EAN13 > http://www.embecosm.com/resources/appnotes/#EAN14 > > We are also planning to talk about AAP at the LLVM Cauldron in Hebden > Bridge. We look forward to discussing our work on AAP with those who are > attending. > > Thank you, > Ed Jones > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 23 August 2016 at 21:28, Alex Rosenberg via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I don't think we've ever really built up clear guidance on this, but I think there needs to be a clear determination that a given target has enough active users to make the maintenance burden worth putting into the mainline.My interpretation of the current guidelines is that the "3 month coll down period" is to make sure the community is active and addresses the problems quickly and effectively enough. Ie. not something for making targets experimental, but certainly for making them official, and keeping the status later on. cheers, --renato
As it stands, the active customers for this target are the out-of-tree backends which we are working on which can't be submitted for inclusion into LLVM. The general aim of the backend though is to include features from architectures which are not well represented in LLVM, for example non-power of two register sizes, non-octet chars, or very constrained register sets, and to this end we hope for it to be useful to the community at large if they are maintaining out-of-tree targets with features they would like LLVM to support. Thanks, Ed On 23/08/16 21:28, Alex Rosenberg wrote:> I don't think we've ever really built up clear guidance on this, but I think there needs to be a clear determination that a given target has enough active users to make the maintenance burden worth putting into the mainline. In the past, the only exception I can think of is the Lanai backend, but in that case we have a strong commitment of multiple employees at a major corporation committed to that target's maintenance. > > So, concretely, can you quantify the active customers for this target? > > Alex > > On Aug 18, 2016, at 12:34 AM, Ed Jones via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> We wish to submit our latest AAP implementation as an experimental >> backend into LLVM. We need community feedback and reviewers for patches >> which we will submit soon. >> >> AAP was designed in early 2015 and aims to advance compiler development >> for small deeply embedded Harvard architectures, which are widely used >> commercially. AAP is freely available as an open source softcore for use >> in FPGA designs. >> >> AAP has wide exposure: at ORCONF16 at CERN, at FOSDEM and at BCS and >> OSHUG meetings. It is also of commercial interest, because of the >> potential benefits of providing upstream LLVM support for features found >> in small embedded processors. >> >> Currently there is a complete Clang and LLVM toolchain including gdb, ld >> and binutils, as well as two simulator implementations. The toolchain is >> passing all LLVM regression tests and a decent proportion of GCC >> regression tests. We are also working on a GCC port to allow comparison >> between compilers, which should be beneficial to both projects. >> >> We believe the code base is sufficiently mature that it is appropriate >> for inclusion. Currently, the full source for AAP can be found on Github: >> https://github.com/embecosm >> >> Details about the ISA, and the hardware implementation can be found on >> our website: >> http://www.embecosm.com/resources/appnotes/#EAN13 >> http://www.embecosm.com/resources/appnotes/#EAN14 >> >> We are also planning to talk about AAP at the LLVM Cauldron in Hebden >> Bridge. We look forward to discussing our work on AAP with those who are >> attending. >> >> Thank you, >> Ed Jones >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
I have now posted the final two patches for the backend to add Disassembler support, ISel and CodeGen. The full list of patches is now: https://reviews.llvm.org/D23664 - AAP triple and target https://reviews.llvm.org/D23665 - ELF definitions https://reviews.llvm.org/D23667 - Stub backend https://reviews.llvm.org/D23770 - InstrInfo, RegInfo Tablegen https://reviews.llvm.org/D23771 - MC layer support https://reviews.llvm.org/D23772 - AsmParser https://reviews.llvm.org/D23773 - InstPrinter https://reviews.llvm.org/D24612 - Disassembler support https://reviews.llvm.org/D24613 - Code generation Currently only the first patch has been accepted, and we are looking for more people to review the remaining patches. Thank you, Ed Jones On 18/08/16 08:34, Ed Jones wrote:> Hi all, > > We wish to submit our latest AAP implementation as an experimental > backend into LLVM. We need community feedback and reviewers for patches > which we will submit soon. > > AAP was designed in early 2015 and aims to advance compiler development > for small deeply embedded Harvard architectures, which are widely used > commercially. AAP is freely available as an open source softcore for use > in FPGA designs. > > AAP has wide exposure: at ORCONF16 at CERN, at FOSDEM and at BCS and > OSHUG meetings. It is also of commercial interest, because of the > potential benefits of providing upstream LLVM support for features found > in small embedded processors. > > Currently there is a complete Clang and LLVM toolchain including gdb, ld > and binutils, as well as two simulator implementations. The toolchain is > passing all LLVM regression tests and a decent proportion of GCC > regression tests. We are also working on a GCC port to allow comparison > between compilers, which should be beneficial to both projects. > > We believe the code base is sufficiently mature that it is appropriate > for inclusion. Currently, the full source for AAP can be found on Github: > https://github.com/embecosm > > Details about the ISA, and the hardware implementation can be found on > our website: > http://www.embecosm.com/resources/appnotes/#EAN13 > http://www.embecosm.com/resources/appnotes/#EAN14 > > We are also planning to talk about AAP at the LLVM Cauldron in Hebden > Bridge. We look forward to discussing our work on AAP with those who are > attending. > > Thank you, > Ed Jones >
Hi all, I have just updated most of the patches to roll them forwards to LLVM top-of-tree, and incorporated various suggested changes. We're still looking for reviewers, if anyone is interested. Thank you, Edward Jones On 15/09/16 17:12, Ed Jones wrote:> I have now posted the final two patches for the backend to add > Disassembler support, ISel and CodeGen. The full list of patches is now: > > https://reviews.llvm.org/D23664 - AAP triple and target > https://reviews.llvm.org/D23665 - ELF definitions > https://reviews.llvm.org/D23667 - Stub backend > https://reviews.llvm.org/D23770 - InstrInfo, RegInfo Tablegen > https://reviews.llvm.org/D23771 - MC layer support > https://reviews.llvm.org/D23772 - AsmParser > https://reviews.llvm.org/D23773 - InstPrinter > https://reviews.llvm.org/D24612 - Disassembler support > https://reviews.llvm.org/D24613 - Code generation > > Currently only the first patch has been accepted, and we are looking for > more people to review the remaining patches. > > Thank you, > Ed Jones > > On 18/08/16 08:34, Ed Jones wrote: >> Hi all, >> >> We wish to submit our latest AAP implementation as an experimental >> backend into LLVM. We need community feedback and reviewers for patches >> which we will submit soon. >> >> AAP was designed in early 2015 and aims to advance compiler development >> for small deeply embedded Harvard architectures, which are widely used >> commercially. AAP is freely available as an open source softcore for use >> in FPGA designs. >> >> AAP has wide exposure: at ORCONF16 at CERN, at FOSDEM and at BCS and >> OSHUG meetings. It is also of commercial interest, because of the >> potential benefits of providing upstream LLVM support for features found >> in small embedded processors. >> >> Currently there is a complete Clang and LLVM toolchain including gdb, ld >> and binutils, as well as two simulator implementations. The toolchain is >> passing all LLVM regression tests and a decent proportion of GCC >> regression tests. We are also working on a GCC port to allow comparison >> between compilers, which should be beneficial to both projects. >> >> We believe the code base is sufficiently mature that it is appropriate >> for inclusion. Currently, the full source for AAP can be found on Github: >> https://github.com/embecosm >> >> Details about the ISA, and the hardware implementation can be found on >> our website: >> http://www.embecosm.com/resources/appnotes/#EAN13 >> http://www.embecosm.com/resources/appnotes/#EAN14 >> >> We are also planning to talk about AAP at the LLVM Cauldron in Hebden >> Bridge. We look forward to discussing our work on AAP with those who are >> attending. >> >> Thank you, >> Ed Jones >>