Hi all, I am proposing the integration of a backend targeting the RISC-V ISA. RISC-V is a free and open instruction set architecture that was originally developed at UC Berkeley. Future development of the ISA specification will be handled by the 501(c)(6) non-profit RISC-V Foundation and its members <https://riscv.org/membership/?action=viewlistings>. You can find much more information at the RISC-V website <https://riscv.org/>, including the current ISA specification <https://riscv.org/specifications/>. You might note that RISC-V defines 32-bit and 64-bit variants and also supports a compressed variant, allowing 16-bit instructions to be freely intermingled with the standard 32-bit representations. The standard is structured to allow implementers to choose appropriate subsets to support, for instance a micro-controller might support 'RV32I' (32-bit RISC-V with the integer instructions) and an application core running Linux might implement RV64IMAFD (commonly shortened to RV64G: 64-bit with integer instructions, the multiply extension, atomics, and single and double precision floating point). A generous portion of the opcode space is left reserved for implementers or researchers to add their own instructions. In line with the proposed policy for adding a new target (https://reviews.llvm.org/D23162), RISC-V has a clear specification, multiple software models, and multiple FPGA implementations as well as prototype ASICs from various groups. At lowRISC (http://www.lowrisc.org/), inspired by our previous experience with the Raspberry Pi project, we are working towards creating a completely open source RISC-V SoC and producing low-cost development boards around it. Feel free to contact me off-list to discuss lowRISC further. LLVM is a key part of our development plan, and with community approval I would like to act as maintainer for the backend. The vast majority of my LLVM work over the past 6 years has sadly been out-of-tree, but I'm far from new to the project. In the RISC-V community right now, GCC is by some way the more stable compiler port. We've discussed best way of moving forward with LLVM at the last couple of RISC-V Workshops and a number of us concluded a fresh codebase may be the best way to move forwards. Producing a series of patches that introduce RISC-V support incrementally in easy-to-review chunks with associated test cases at every point also allows us to get the maximum benefit from LLVM's code review procedure. It also provides a good basis for more detailed documentation on writing an LLVM backend (and making modifications to an existing one, e.g. making it much easier for a research group wanting to explore RISC-V changes). This is an area I also hope to contribute to. The approach of small, incremental patches is somewhat similar to what is being done with the AVR backend. I'm grateful to David Chisnall who suggested that starting with the MC layer may be a productive way to go about developing this backend, and so far this seems to be working well. The current status is that I have submitted a series of 10 patches implementing assembler support and an initial set of relocations and fixups. Help reviewing these would be very welcome, do let me know if you'd like to be CCed in or added as a reviewer to future patches. I'd ultimately like the RISC-V backend to be considered a "reference" backend, and as such I specifically welcome reviews you might worry are pedantic. Please find the current set of patches for your review here: * <https://reviews.llvm.org/differential/?authors=asb> I've obviously spent a lot of time with the MC layer recently, and I'd be happy to put that to use in helping review MC patches for other archs. Mini development roadmap: * Complete MC layer (supporting up to RV32+RV64G at least) * There is currently no specification for supported RISC-V assembly syntax, mnemonics etc. The ideal solution may not always be "whatever the GCC port currently does", so some aspect of this will involve discussions with the wider RISC-V software community. * Codegen * Compressed instruction set support (RVC) * Benchmarking and comparison to GCC RISC-V (and potentially other archs) Finally I'd like to give a prominent mention to Colin Schmidt, the UC Berkeley student who has been maintaining the current out-of-tree RISC-V LLVM port <https://github.com/riscv/riscv-llvm>. The RISC-V community owes him a debt of gratitude. All comments very welcome, Alex
On 17 August 2016 at 02:14, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:> All comments very welcome,I think it's a great idea! RISC--V is a really interesting project, and I've thought it was a shame that we don't have a backend in trunk for a while. I'll see if I have any comments on the patches. Tim.
----- Original Message -----> From: "Alex Bradbury via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, August 17, 2016 4:14:38 AM > Subject: [llvm-dev] [RFC] RISC-V backend > > Hi all, > > I am proposing the integration of a backend targeting the RISC-V ISA. > > RISC-V is a free and open instruction set architecture that was > originally > developed at UC Berkeley. Future development of the ISA specification > will be > handled by the 501(c)(6) non-profit RISC-V Foundation and its members > <https://riscv.org/membership/?action=viewlistings>. You can find > much more > information at the RISC-V website <https://riscv.org/>, including the > current > ISA specification <https://riscv.org/specifications/>. You might note > that > RISC-V defines 32-bit and 64-bit variants and also supports a > compressed > variant, allowing 16-bit instructions to be freely intermingled with > the > standard 32-bit representations. The standard is structured to allow > implementers to choose appropriate subsets to support, for instance a > micro-controller might support 'RV32I' (32-bit RISC-V with the > integer > instructions) and an application core running Linux might implement > RV64IMAFD > (commonly shortened to RV64G: 64-bit with integer instructions, the > multiply > extension, atomics, and single and double precision floating point). > A > generous portion of the opcode space is left reserved for > implementers or > researchers to add their own instructions. > > In line with the proposed policy for adding a new target > (https://reviews.llvm.org/D23162), RISC-V has a clear specification, > multiple > software models, and multiple FPGA implementations as well as > prototype ASICs > from various groups. At lowRISC (http://www.lowrisc.org/), inspired > by our > previous experience with the Raspberry Pi project, we are working > towards > creating a completely open source RISC-V SoC and producing low-cost > development boards around it. Feel free to contact me off-list to > discuss > lowRISC further. LLVM is a key part of our development plan, and with > community approval I would like to act as maintainer for the backend. > The vast > majority of my LLVM work over the past 6 years has sadly been > out-of-tree, but > I'm far from new to the project. > > In the RISC-V community right now, GCC is by some way the more stable > compiler > port. We've discussed best way of moving forward with LLVM at the > last couple > of RISC-V Workshops and a number of us concluded a fresh codebase may > be the > best way to move forwards. Producing a series of patches that > introduce RISC-V > support incrementally in easy-to-review chunks with associated test > cases at > every point also allows us to get the maximum benefit from LLVM's > code review > procedure.Yes, this is exactly the process we should follow when practical. I'm in favor of this effort. -Hal> It also provides a good basis for more detailed > documentation on > writing an LLVM backend (and making modifications to an existing one, > e.g. > making it much easier for a research group wanting to explore RISC-V > changes). > This is an area I also hope to contribute to. The approach of small, > incremental patches is somewhat similar to what is being done with > the AVR > backend. I'm grateful to David Chisnall who suggested that starting > with the > MC layer may be a productive way to go about developing this backend, > and so > far this seems to be working well. > > The current status is that I have submitted a series of 10 patches > implementing assembler support and an initial set of relocations and > fixups. > Help reviewing these would be very welcome, do let me know if you'd > like to be > CCed in or added as a reviewer to future patches. I'd ultimately like > the > RISC-V backend to be considered a "reference" backend, and as such > I specifically welcome reviews you might worry are pedantic. > > Please find the current set of patches for your review here: > * <https://reviews.llvm.org/differential/?authors=asb> > > I've obviously spent a lot of time with the MC layer recently, and > I'd be > happy to put that to use in helping review MC patches for other > archs. > > Mini development roadmap: > * Complete MC layer (supporting up to RV32+RV64G at least) > * There is currently no specification for supported RISC-V assembly > syntax, > mnemonics etc. The ideal solution may not always be "whatever the > GCC port > currently does", so some aspect of this will involve discussions > with the > wider RISC-V software community. > * Codegen > * Compressed instruction set support (RVC) > * Benchmarking and comparison to GCC RISC-V (and potentially other > archs) > > Finally I'd like to give a prominent mention to Colin Schmidt, the UC > Berkeley > student who has been maintaining the current out-of-tree RISC-V LLVM > port > <https://github.com/riscv/riscv-llvm>. The RISC-V community owes him > a debt of > gratitude. > > All comments very welcome, > > Alex > _______________________________________________ > 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 Aug 17, 2016, at 8:49 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Alex Bradbury via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "llvm-dev" <llvm-dev at lists.llvm.org> >> Sent: Wednesday, August 17, 2016 4:14:38 AM >> Subject: [llvm-dev] [RFC] RISC-V backend >> >> Hi all, >> >> I am proposing the integration of a backend targeting the RISC-V ISA. >> >> RISC-V is a free and open instruction set architecture that was >> originally >> developed at UC Berkeley. Future development of the ISA specification >> will be >> handled by the 501(c)(6) non-profit RISC-V Foundation and its members >> <https://riscv.org/membership/?action=viewlistings>. You can find >> much more >> information at the RISC-V website <https://riscv.org/>, including the >> current >> ISA specification <https://riscv.org/specifications/>. You might note >> that >> RISC-V defines 32-bit and 64-bit variants and also supports a >> compressed >> variant, allowing 16-bit instructions to be freely intermingled with >> the >> standard 32-bit representations. The standard is structured to allow >> implementers to choose appropriate subsets to support, for instance a >> micro-controller might support 'RV32I' (32-bit RISC-V with the >> integer >> instructions) and an application core running Linux might implement >> RV64IMAFD >> (commonly shortened to RV64G: 64-bit with integer instructions, the >> multiply >> extension, atomics, and single and double precision floating point). >> A >> generous portion of the opcode space is left reserved for >> implementers or >> researchers to add their own instructions. >> >> In line with the proposed policy for adding a new target >> (https://reviews.llvm.org/D23162), RISC-V has a clear specification, >> multiple >> software models, and multiple FPGA implementations as well as >> prototype ASICs >> from various groups. At lowRISC (http://www.lowrisc.org/), inspired >> by our >> previous experience with the Raspberry Pi project, we are working >> towards >> creating a completely open source RISC-V SoC and producing low-cost >> development boards around it. Feel free to contact me off-list to >> discuss >> lowRISC further. LLVM is a key part of our development plan, and with >> community approval I would like to act as maintainer for the backend. >> The vast >> majority of my LLVM work over the past 6 years has sadly been >> out-of-tree, but >> I'm far from new to the project. >> >> In the RISC-V community right now, GCC is by some way the more stable >> compiler >> port. We've discussed best way of moving forward with LLVM at the >> last couple >> of RISC-V Workshops and a number of us concluded a fresh codebase may >> be the >> best way to move forwards. Producing a series of patches that >> introduce RISC-V >> support incrementally in easy-to-review chunks with associated test >> cases at >> every point also allows us to get the maximum benefit from LLVM's >> code review >> procedure. > > Yes, this is exactly the process we should follow when practical. I'm in favor of this effort.+1 Thanks Alex! — Mehdi> > >> It also provides a good basis for more detailed >> documentation on >> writing an LLVM backend (and making modifications to an existing one, >> e.g. >> making it much easier for a research group wanting to explore RISC-V >> changes). >> This is an area I also hope to contribute to. The approach of small, >> incremental patches is somewhat similar to what is being done with >> the AVR >> backend. I'm grateful to David Chisnall who suggested that starting >> with the >> MC layer may be a productive way to go about developing this backend, >> and so >> far this seems to be working well. >> >> The current status is that I have submitted a series of 10 patches >> implementing assembler support and an initial set of relocations and >> fixups. >> Help reviewing these would be very welcome, do let me know if you'd >> like to be >> CCed in or added as a reviewer to future patches. I'd ultimately like >> the >> RISC-V backend to be considered a "reference" backend, and as such >> I specifically welcome reviews you might worry are pedantic. >> >> Please find the current set of patches for your review here: >> * <https://reviews.llvm.org/differential/?authors=asb> >> >> I've obviously spent a lot of time with the MC layer recently, and >> I'd be >> happy to put that to use in helping review MC patches for other >> archs. >> >> Mini development roadmap: >> * Complete MC layer (supporting up to RV32+RV64G at least) >> * There is currently no specification for supported RISC-V assembly >> syntax, >> mnemonics etc. The ideal solution may not always be "whatever the >> GCC port >> currently does", so some aspect of this will involve discussions >> with the >> wider RISC-V software community. >> * Codegen >> * Compressed instruction set support (RVC) >> * Benchmarking and comparison to GCC RISC-V (and potentially other >> archs) >> >> Finally I'd like to give a prominent mention to Colin Schmidt, the UC >> Berkeley >> student who has been maintaining the current out-of-tree RISC-V LLVM >> port >> <https://github.com/riscv/riscv-llvm>. The RISC-V community owes him >> a debt of >> gratitude. >> >> All comments very welcome, >> >> Alex >> _______________________________________________ >> 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20160817/e64ad657/attachment.html>
On Wed, Aug 17, 2016 at 5:14 AM, Alex Bradbury via llvm-dev < llvm-dev at lists.llvm.org> wrote:> In the RISC-V community right now, GCC is by some way the more stable > compiler > port. We've discussed best way of moving forward with LLVM at the last > couple > of RISC-V Workshops and a number of us concluded a fresh codebase may be > the > best way to move forwards. Producing a series of patches that introduce > RISC-V > support incrementally in easy-to-review chunks with associated test cases > at > every point also allows us to get the maximum benefit from LLVM's code > review > procedure. It also provides a good basis for more detailed documentation on > writing an LLVM backend (and making modifications to an existing one, e.g. > making it much easier for a research group wanting to explore RISC-V > changes). > This is an area I also hope to contribute to. The approach of small, > incremental patches is somewhat similar to what is being done with the AVR > backend. I'm grateful to David Chisnall who suggested that starting with > the > MC layer may be a productive way to go about developing this backend, and > so > far this seems to be working well. >This sounds like a great plan. The only concern I have is that the process actually finish, and not end up in a limbo state for a year. I haven't actually been following the story of the AVR backend at all, but afaik the current status is that there's a partially completed AVR backend in trunk that's been under construction for a year or so, and a functional backend in another repository, which people actually use. However that situation came to pass, it seems a very unfortunate state to be in, and it would be sad if this rewrite of the RISC-V backend ended up with the upstream repository having the same mostly-unusable status for RISC-V. Note, I want to stress I am __not__ disagreeing with your proposed plan! I just want to mention that concern. I'd ultimately like the> RISC-V backend to be considered a "reference" backend, and as such > I specifically welcome reviews you might worry are pedantic. >Yes, it would probably make a lot of sense to transition the WritingAnLLVMBackend document from describing the SPARC backend to the RISC-V backend, at some future point.> Mini development roadmap: > * Complete MC layer (supporting up to RV32+RV64G at least)* There is currently no specification for supported RISC-V assembly> syntax, > mnemonics etc. The ideal solution may not always be "whatever the GCC > port > currently does", so some aspect of this will involve discussions with the > wider RISC-V software community. >I would suggest starting CodeGen before getting too far into MC, since a lot of things about the instruction definitions are only for codegen, it's easy to make something that works for MC but isn't structured right for codegen. That is to say, I'd recommend starting codegen after doing MC through RV32G+RV64G at *most*, rather than at *least*, and it might even make sense to start on CodeGen support after only RV32I/RV64I. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/d01abd1a/attachment.html>
On 17 August 2016 at 17:33, James Y Knight <jyknight at google.com> wrote:> On Wed, Aug 17, 2016 at 5:14 AM, Alex Bradbury via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> In the RISC-V community right now, GCC is by some way the more stable >> compiler >> port. We've discussed best way of moving forward with LLVM at the last >> couple >> of RISC-V Workshops and a number of us concluded a fresh codebase may be >> the >> best way to move forwards. Producing a series of patches that introduce >> RISC-V >> support incrementally in easy-to-review chunks with associated test cases >> at >> every point also allows us to get the maximum benefit from LLVM's code >> review >> procedure. It also provides a good basis for more detailed documentation >> on >> writing an LLVM backend (and making modifications to an existing one, e.g. >> making it much easier for a research group wanting to explore RISC-V >> changes). >> This is an area I also hope to contribute to. The approach of small, >> incremental patches is somewhat similar to what is being done with the AVR >> backend. I'm grateful to David Chisnall who suggested that starting with >> the >> MC layer may be a productive way to go about developing this backend, and >> so >> far this seems to be working well. > > > This sounds like a great plan. The only concern I have is that the process > actually finish, and not end up in a limbo state for a year. > > I haven't actually been following the story of the AVR backend at all, but > afaik the current status is that there's a partially completed AVR backend > in trunk that's been under construction for a year or so, and a functional > backend in another repository, which people actually use. However that > situation came to pass, it seems a very unfortunate state to be in, and it > would be sad if this rewrite of the RISC-V backend ended up with the > upstream repository having the same mostly-unusable status for RISC-V. > > Note, I want to stress I am __not__ disagreeing with your proposed plan! I > just want to mention that concern.That's a fair concern. I think the upstreaming of AVR has been slower than hoped because 1) as I understand it, it's a spare time project for everyone involved 2) Dylan has found it difficult to get code reviewers - it remains to be seen how problematic that will be for RISC-V, but there's certainly a lot of RISC-V interest 3) AVR is I think in general a more difficult target lowRISC CIC (the UK not-for-profit we set up to support the lowRISC efforts) is now becoming my full time focus, and as part of that the majority of my time will, for some time, be on RISC-V LLVM. To move faster, we of course welcome additional support in the form of either engineering time or sponsorship from any parties interested in open source hardware, the RISC-V ecosystem, or LLVM+RISC-V more specifically.>> Mini development roadmap: >> * Complete MC layer (supporting up to RV32+RV64G at least) >> >> * There is currently no specification for supported RISC-V assembly >> syntax, >> mnemonics etc. The ideal solution may not always be "whatever the GCC >> port >> currently does", so some aspect of this will involve discussions with >> the >> wider RISC-V software community. > > > I would suggest starting CodeGen before getting too far into MC, since a lot > of things about the instruction definitions are only for codegen, it's easy > to make something that works for MC but isn't structured right for codegen. > That is to say, I'd recommend starting codegen after doing MC through > RV32G+RV64G at *most*, rather than at *least*, and it might even make sense > to start on CodeGen support after only RV32I/RV64I.That's a really good point. I was hoping to have completed some CodeGen to have fully proven the MC-first approach before submitting, but getting everything lined up to move to lowRISC full-time took more time than I anticipated. I think the milestone I really want to hit is where I can easily cross-validate against gcc - i.e. assembling its .s output. I think we're actually almost at the point where I can do that, and I agree there's a lot of value in getting the CodeGen support well underway. Not least, once there's a reasonable CodeGen and MC baseline I think it will be somewhat easier for more people to work in parallel on additional features and optimisations. I'll aim to move to CodeGen ASAP. Thanks, Alex
On 08/17/2016 09:33 AM, James Y Knight via llvm-dev wrote:> > I haven't actually been following the story of the AVR backend at all, > but afaik the current status is that there's a partially completed AVR > backend in trunk that's been under construction for a year or so, and > a functional backend in another repository, which people actually use. > However that situation came to pass, it seems a very unfortunate state > to be in, and it would be sad if this rewrite of the RISC-V backend > ended up with the upstream repository having the same mostly-unusable > status for RISC-V.The problem is nobody is reviewing it. I've reviewed a number of patches, but the current set of ones up for review are for MC areas I'm not the best person for -Matt
Slightly off-topic, but if you want to port the entire toolchain to RISC-V, you may want to add RISC-V support to LLD. I took a quick look at the specification a few months ago and found that that's pretty straightforward EFL ABI, so I expect you only need a few hundred lines of new code to support RISC-V. I actually tried to do that at that moment as my weekend project but gave up because I found that no code was upstreamed. On Wed, Aug 17, 2016 at 2:14 AM, Alex Bradbury via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > I am proposing the integration of a backend targeting the RISC-V ISA. > > RISC-V is a free and open instruction set architecture that was originally > developed at UC Berkeley. Future development of the ISA specification will > be > handled by the 501(c)(6) non-profit RISC-V Foundation and its members > <https://riscv.org/membership/?action=viewlistings>. You can find much > more > information at the RISC-V website <https://riscv.org/>, including the > current > ISA specification <https://riscv.org/specifications/>. You might note that > RISC-V defines 32-bit and 64-bit variants and also supports a compressed > variant, allowing 16-bit instructions to be freely intermingled with the > standard 32-bit representations. The standard is structured to allow > implementers to choose appropriate subsets to support, for instance a > micro-controller might support 'RV32I' (32-bit RISC-V with the integer > instructions) and an application core running Linux might implement > RV64IMAFD > (commonly shortened to RV64G: 64-bit with integer instructions, the > multiply > extension, atomics, and single and double precision floating point). A > generous portion of the opcode space is left reserved for implementers or > researchers to add their own instructions. > > In line with the proposed policy for adding a new target > (https://reviews.llvm.org/D23162), RISC-V has a clear specification, > multiple > software models, and multiple FPGA implementations as well as prototype > ASICs > from various groups. At lowRISC (http://www.lowrisc.org/), inspired by our > previous experience with the Raspberry Pi project, we are working towards > creating a completely open source RISC-V SoC and producing low-cost > development boards around it. Feel free to contact me off-list to discuss > lowRISC further. LLVM is a key part of our development plan, and with > community approval I would like to act as maintainer for the backend. The > vast > majority of my LLVM work over the past 6 years has sadly been out-of-tree, > but > I'm far from new to the project. > > In the RISC-V community right now, GCC is by some way the more stable > compiler > port. We've discussed best way of moving forward with LLVM at the last > couple > of RISC-V Workshops and a number of us concluded a fresh codebase may be > the > best way to move forwards. Producing a series of patches that introduce > RISC-V > support incrementally in easy-to-review chunks with associated test cases > at > every point also allows us to get the maximum benefit from LLVM's code > review > procedure. It also provides a good basis for more detailed documentation on > writing an LLVM backend (and making modifications to an existing one, e.g. > making it much easier for a research group wanting to explore RISC-V > changes). > This is an area I also hope to contribute to. The approach of small, > incremental patches is somewhat similar to what is being done with the AVR > backend. I'm grateful to David Chisnall who suggested that starting with > the > MC layer may be a productive way to go about developing this backend, and > so > far this seems to be working well. > > The current status is that I have submitted a series of 10 patches > implementing assembler support and an initial set of relocations and > fixups. > Help reviewing these would be very welcome, do let me know if you'd like > to be > CCed in or added as a reviewer to future patches. I'd ultimately like the > RISC-V backend to be considered a "reference" backend, and as such > I specifically welcome reviews you might worry are pedantic. > > Please find the current set of patches for your review here: > * <https://reviews.llvm.org/differential/?authors=asb> > > I've obviously spent a lot of time with the MC layer recently, and I'd be > happy to put that to use in helping review MC patches for other archs. > > Mini development roadmap: > * Complete MC layer (supporting up to RV32+RV64G at least) > * There is currently no specification for supported RISC-V assembly > syntax, > mnemonics etc. The ideal solution may not always be "whatever the GCC > port > currently does", so some aspect of this will involve discussions with the > wider RISC-V software community. > * Codegen > * Compressed instruction set support (RVC) > * Benchmarking and comparison to GCC RISC-V (and potentially other archs) > > Finally I'd like to give a prominent mention to Colin Schmidt, the UC > Berkeley > student who has been maintaining the current out-of-tree RISC-V LLVM port > <https://github.com/riscv/riscv-llvm>. The RISC-V community owes him a > debt of > gratitude. > > All comments very welcome, > > Alex > _______________________________________________ > 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/20160817/e4173646/attachment.html>
On 17 August 2016 at 20:55, Rui Ueyama <ruiu at google.com> wrote:> Slightly off-topic, but if you want to port the entire toolchain to RISC-V, > you may want to add RISC-V support to LLD. I took a quick look at the > specification a few months ago and found that that's pretty straightforward > EFL ABI, so I expect you only need a few hundred lines of new code to > support RISC-V. I actually tried to do that at that moment as my weekend > project but gave up because I found that no code was upstreamed.I'd love LLD support - I'll eventually get round to it if nobody else does but I'd really welcome someone more familiar with LLD internals to take it on. Rafael has also expressed an interest, so that's two people who are massively over-qualified in that respect :) Best, Alex
On 17 August 2016 at 10:14, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I am proposing the integration of a backend targeting the RISC-V ISA.+1!> In line with the proposed policy for adding a new target > (https://reviews.llvm.org/D23162), RISC-V has a clear specification, multiple > software models, and multiple FPGA implementations as well as prototype ASICs > from various groups. At lowRISC (http://www.lowrisc.org/), inspired by our > previous experience with the Raspberry Pi project, we are working towards > creating a completely open source RISC-V SoC and producing low-cost > development boards around it. Feel free to contact me off-list to discuss > lowRISC further. LLVM is a key part of our development plan, and with > community approval I would like to act as maintainer for the backend. The vast > majority of my LLVM work over the past 6 years has sadly been out-of-tree, but > I'm far from new to the project.The policy has been updated and accepted by Chris and is now at: http://llvm.org/docs/DeveloperPolicy.html#new-targets Basically, in addition to the previous proposal, it requires a code owner to come forward, which you just did. :) Code owner: check Community: check Compatible code: check Policies: AFAICS, check License: check Docs / Impl: check The code seem to have been reviewed and largely accepted, and your responses to code review were quick and good.>From what I can see, the RISC-V target & community checks all the boxes.> It also provides a good basis for more detailed documentation on > writing an LLVM backend (and making modifications to an existing one, e.g. > making it much easier for a research group wanting to explore RISC-V changes).This would be fantastic!> I've obviously spent a lot of time with the MC layer recently, and I'd be > happy to put that to use in helping review MC patches for other archs.This also checks the box for "helpful community". :)> Mini development roadmap: > * Complete MC layer (supporting up to RV32+RV64G at least) > * There is currently no specification for supported RISC-V assembly syntax, > mnemonics etc. The ideal solution may not always be "whatever the GCC port > currently does", so some aspect of this will involve discussions with the > wider RISC-V software community.Maybe some more documentation is in order, but this can start slow and converge to a future standard. One problem that might happen is that GNU asm output will have to be accepted, so in doubt, following what they do would be the least amount of work. But in the long run, you'll want something consistent and well written (to be considered the go-to back-end), and if the RISC-V community decides LLVM is the default compiler, following an agreed spec, then GCC will have no option but to follow the spec.> * Codegen > * Compressed instruction set support (RVC) > * Benchmarking and comparison to GCC RISC-V (and potentially other archs)What about buildbots? I'm assuming "check-all" would be enough for now, but you'll have to have at least one buildbot that builds the back-end (which for now will be experimental, and will need an additional CMake flag). But in the long run, you'll want to run the test-suite, even if on a simulator, and who knows, maybe even self-host Clang in your target! cheers, --renato
On 18 August 2016 at 00:08, Renato Golin <renato.golin at linaro.org> wrote:> On 17 August 2016 at 10:14, Alex Bradbury via llvm-dev >> * Codegen >> * Compressed instruction set support (RVC) >> * Benchmarking and comparison to GCC RISC-V (and potentially other archs) > > What about buildbots? > > I'm assuming "check-all" would be enough for now, but you'll have to > have at least one buildbot that builds the back-end (which for now > will be experimental, and will need an additional CMake flag). > > But in the long run, you'll want to run the test-suite, even if on a > simulator, and who knows, maybe even self-host Clang in your target!Good question, I didn't mention buildbots in this RFC as from a quick look at http://lab.llvm.org:8011/builders it didn't look like early-stage architecture ports tend to have one, and as you say check-all should be be enough initially. I'm sure that we (i.e. lowRISC CIC) can support an additional buildbot when appropriate. Is there any recommendation on minimum specification? At what point do you think providing an extra buildbot would become a priority? If any additional value can be provided by doing so I'd definitely like to have a buildbot before RISC-V becomes an 'official' rather than 'experimental' arch. Best, Alex
On 17 August 2016 at 10:14, Alex Bradbury <asb at asbradbury.org> wrote:> The current status is that I have submitted a series of 10 patches > implementing assembler support and an initial set of relocations and fixups. > Help reviewing these would be very welcome, do let me know if you'd like to be > CCed in or added as a reviewer to future patches. I'd ultimately like the > RISC-V backend to be considered a "reference" backend, and as such > I specifically welcome reviews you might worry are pedantic. > > Please find the current set of patches for your review here: > * <https://reviews.llvm.org/differential/?authors=asb>I have just refreshed the whole set of patches, which now address all review comments received so far. Many thanks to everyone who has taken the time to review. I will host a buildslve connected to the 'silent staging buildbot' to provide public build status once the RISC-V backend starts getting committed. Additionally, Colin Schmidt and I have submitted a proposal for a RISC-V related Birds of a Feather session at the 2016 US LLVM Developers' Meeting. If that is accepted it may be a good venue for further discussion about more long-term plans. Does anybody have any other thoughts on the addition of RISC-V to LLVM? Best, Alex
On Fri, Aug 26, 2016, at 02:44 PM, Alex Bradbury via llvm-dev wrote:> On 17 August 2016 at 10:14, Alex Bradbury <asb at asbradbury.org> wrote: > > The current status is that I have submitted a series of 10 patches > > implementing assembler support and an initial set of relocations and fixups. > > Help reviewing these would be very welcome, do let me know if you'd like to be > > CCed in or added as a reviewer to future patches. I'd ultimately like the > > RISC-V backend to be considered a "reference" backend, and as such > > I specifically welcome reviews you might worry are pedantic. > > > > Please find the current set of patches for your review here: > > * <https://reviews.llvm.org/differential/?authors=asb> > > I have just refreshed the whole set of patches, which now address all > review comments received so far. Many thanks to everyone who has taken > the time to review. > > I will host a buildslve connected to the 'silent staging buildbot' to > provide public build status once the RISC-V backend starts getting > committed. Additionally, Colin Schmidt and I have submitted a proposal > for a RISC-V related Birds of a Feather session at the 2016 US LLVM > Developers' Meeting. If that is accepted it may be a good venue for > further discussion about more long-term plans. > > Does anybody have any other thoughts on the addition of RISC-V to LLVM?Hey Alex, even though not being involved in the reviews itself, as an observer it seems to me you clearly reached your goal as being a "good example" for a new back end. I think we can keep this discussion and the corresponding reviews as an example of how to upstream a new back end. And also how -- as a community -- welcome a new back end. It was a pleasure to follow this discussion. Best, Tobias
On 17 August 2016 at 10:14, Alex Bradbury <asb at asbradbury.org> wrote:> The current status is that I have submitted a series of 10 patches > implementing assembler support and an initial set of relocations and fixups. > Help reviewing these would be very welcome, do let me know if you'd like to be > CCed in or added as a reviewer to future patches. I'd ultimately like the > RISC-V backend to be considered a "reference" backend, and as such > I specifically welcome reviews you might worry are pedantic. > > Please find the current set of patches for your review here: > * <https://reviews.llvm.org/differential/?authors=asb>Hi all, I wanted to share an update on the current status of things. * https://reviews.llvm.org/D23557 1/10. RISC-V triple parsing code. Reviewed and ready to land * https://reviews.llvm.org/D23558 2/10. RISC-V ELF defines. Reviewed and ready to land * https://reviews.llvm.org/D23560 3/10. Stub RISC-V backend. Reviewed and ready to land * https://reviews.llvm.org/D23561 4/10. Add basic .td files. Reviewed, but really needs another look from reviewers due to a revised patch * https://reviews.llvm.org/D23496 Move OperandMatchResultTy to MCTargetAsmParser. Unreviewed. * https://reviews.llvm.org/D23562. 5/10. Add bare-bones RISC-V MCTargetDesc. Reviewed and ready to land. * https://reviews.llvm.org/D23563 6/10. Add basic RISCVAsmParser. Review comments addressed, needs acceptance. * https://reviews.llvm.org/D23564 7/10. Add RISCVInstPrinter and basic tests. Reviewed and ready to land. * https://reviews.llvm.org/D23566 8/10. Add support for all RV32I instructions. Review comments addressed, needs acceptance * https://reviews.llvm.org/D23567 9/10. Add support for disassembly. Reviewed and ready to land. * https://reviews.llvm.org/D23568 10/10. Add fixups and relocations necessary for %hi, %lo and friends. Awaiting review So 6 are reviewed and ready to land, 3 have started the review process and awaiting signoff, and 2 remain unreviewed. Many thanks to everyone who has chipped in with review comments, the patches have improved significantly as a result. If you would like to help, but poring through backend code doesn't appeal to you, it would be really great to: 1) Review this minor patch that moves the definition of OperandMatchResultTy to a header rather than in tblgenned code 2) Check out the discussion about variable-sized register classes. It raises lots of interesting questions, and an improvement to LLVM here could benefit multiple backends, including RISC-V <http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html>. I'm not blocked on this, but would prefer to use something like this proposal to avoid having to define every instruction twice (once for RV32, again for RV64). I'm really pleased that I'll be able to make it over to the US LLVM Developers' Meeting in November. The BoF submission Colin and I put in sadly wasn't accepted, but perhaps a few people may be interested in having the sort of discussion we proposed in a more informal setting (i.e. the 'corridor track' - just say hi!): * The open nature of RISC-V gives a unique opportunity to contribute to its development. How can we, as compiler engineers best contribute our expertise to this effort? * How can we rapidly achieve first-class RISC-V support across LLVM projects? * What can we do to make LLVM more accessible to groups performing computer architecture research using RISC-V? * Are there lessons to be learned from the history of other architectures in LLVM, mistakes that we can avoid? * What can we do to track improvements (or regressions) in performance and code size over time? * Are there areas where the RISC-V community can contribute to the general LLVM infrastructure? e.g. moving target-specific passes to the middle-end. * There is a potential for a large diversity in RISC-V implementations with support for different instruction set subsets or new custom instructions. How can LLVM deal with this? Best, Alex
Hi, I’m pretty interested in developing RISC-V backend. But the information across mailing list, upstream codebase and the riscv.org <http://riscv.org/> website is a little bit scattered and confused. Here are some facts I’ve known: 1. Colin has finished a great job on https://github.com/riscv/riscv-llvm <https://github.com/riscv/riscv-llvm>, the riscv-trunk branch is upstreaming with the trunk 2. There is also a clang frontend on https://github.com/riscv/riscv-clang <https://github.com/riscv/riscv-clang>. I guess the riscv-trunk branch is also upstreaming with the trunk 3. Alex had submitted some patches for code review. About 7 of them is not accepted yet 4. Currently the upstream codebase are mostly consist of MC part. Seems that it’s not able to be tested from llc Please correct me if I’m wrong. My question is: 1. Probably the biggest one: What’s next step? I’m neither the expert of RISCV nor good at backend development so I’m afraid I can’t review the patches. But I’m willing to develop the ISel and scheduling part. Is helping to port the work from Colin’s github repo to upstream codebase a good starting point? 2. What’s the clang’s status? I know it’s a little bit weird to ask in this mailing list but Colin’s work on github seems to be paused and there is no patches submitted to the code review, I just want to know whether helping to port the work from github to upstream would also be a good idea. Best Regards, Bekket McClane> Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> 於 2016年10月10日 上午5:41 寫道： > > On 17 August 2016 at 10:14, Alex Bradbury <asb at asbradbury.org> wrote: >> The current status is that I have submitted a series of 10 patches >> implementing assembler support and an initial set of relocations and fixups. >> Help reviewing these would be very welcome, do let me know if you'd like to be >> CCed in or added as a reviewer to future patches. I'd ultimately like the >> RISC-V backend to be considered a "reference" backend, and as such >> I specifically welcome reviews you might worry are pedantic. >> >> Please find the current set of patches for your review here: >> * <https://reviews.llvm.org/differential/?authors=asb> > > Hi all, I wanted to share an update on the current status of things. > > * https://reviews.llvm.org/D23557 1/10. RISC-V triple parsing code. > Reviewed and ready to land > * https://reviews.llvm.org/D23558 2/10. RISC-V ELF defines. Reviewed > and ready to land > * https://reviews.llvm.org/D23560 3/10. Stub RISC-V backend. Reviewed > and ready to land > * https://reviews.llvm.org/D23561 4/10. Add basic .td files. Reviewed, > but really needs another look from reviewers due to a revised patch > * https://reviews.llvm.org/D23496 Move OperandMatchResultTy to > MCTargetAsmParser. Unreviewed. > * https://reviews.llvm.org/D23562. 5/10. Add bare-bones RISC-V > MCTargetDesc. Reviewed and ready to land. > * https://reviews.llvm.org/D23563 6/10. Add basic RISCVAsmParser. > Review comments addressed, needs acceptance. > * https://reviews.llvm.org/D23564 7/10. Add RISCVInstPrinter and basic > tests. Reviewed and ready to land. > * https://reviews.llvm.org/D23566 8/10. Add support for all RV32I > instructions. Review comments addressed, needs acceptance > * https://reviews.llvm.org/D23567 9/10. Add support for disassembly. > Reviewed and ready to land. > * https://reviews.llvm.org/D23568 10/10. Add fixups and relocations > necessary for %hi, %lo and friends. Awaiting review > > So 6 are reviewed and ready to land, 3 have started the review process > and awaiting signoff, and 2 remain unreviewed. Many thanks to everyone > who has chipped in with review comments, the patches have improved > significantly as a result. > > If you would like to help, but poring through backend code doesn't > appeal to you, it would be really great to: > 1) Review this minor patch that moves the definition of > OperandMatchResultTy to a header rather than in tblgenned code > 2) Check out the discussion about variable-sized register classes. It > raises lots of interesting questions, and an improvement to LLVM here > could benefit multiple backends, including RISC-V > <http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html>. > I'm not blocked on this, but would prefer to use something like this > proposal to avoid having to define every instruction twice (once for > RV32, again for RV64). > > I'm really pleased that I'll be able to make it over to the US LLVM > Developers' Meeting in November. The BoF submission Colin and I put in > sadly wasn't accepted, but perhaps a few people may be interested in > having the sort of discussion we proposed in a more informal setting > (i.e. the 'corridor track' - just say hi!): > > * The open nature of RISC-V gives a unique opportunity to contribute > to its development. How can we, as compiler engineers best contribute > our expertise to this effort? > * How can we rapidly achieve first-class RISC-V support across LLVM projects? > * What can we do to make LLVM more accessible to groups performing > computer architecture research using RISC-V? > * Are there lessons to be learned from the history of other > architectures in LLVM, mistakes that we can avoid? > * What can we do to track improvements (or regressions) in performance > and code size over time? > * Are there areas where the RISC-V community can contribute to the > general LLVM infrastructure? e.g. moving target-specific passes to the > middle-end. > * There is a potential for a large diversity in RISC-V implementations > with support for different instruction set subsets or new custom > instructions. How can LLVM deal with this? > > Best, > > Alex > _______________________________________________ > 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/20170529/61933edb/attachment.html>
Reasonably Related Threads
- RISC-V LLVM status update
- Support 64-bit pointers in open source RV32 GPU ISA using register pairs and address space ID’s
- Support 64-bit pointers in open source RV32 GPU ISA using register pairs and address space ID’s
- RISC-V LLVM sync-up call 19 Mar 2020
- [RFC] RISC-V backend