similar to: [RFC] RISC-V backend

As you will have seen from previous postings, I've been working on upstream LLVM support for the RISC-V instruction set architecture. The initial RFC <http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html> provides a good overview of my approach. Thanks to funding from a third party, I've recently been able to return to this effort as my main focus. Now feels like a good

> > Hi Reshabh, and congratulations on being selected for GSoC. I haven't > looked at supporting larger than native-width pointers on a target > before. I'd thought that AVR might be relevant (given it uses 16-bit > pointers but has 8-bit GPRs). See the description here > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html>. > Many thanks Alex,

Hello everyone, We are working on extending RISC-V LLVM backend which will help us to achieve the goal of improving programmability in the second generation design of our open source RISC-V manycore processor (bjump.org/manycore). We started with supporting 64 bit pointers in RISCV 32 bit backend using address spaces and register pairs. We aim to support 64 bit pointers in address space 1 using

Hi, Sam. I think that it's a fair comparison. Keep in mind that the GP is only used to reach global variables of local scope and the GOT, where the address of global variables of global scope reside. This model assumes that the distance between the GP and the global data area, GOT and local scope variables is defined at link time. __ Evandro Menezes ◊ SiFive ◊ Austin, TX > On Mar

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

On Wed, 22 Jan 2020 at 19:55, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Jan 21, 2020, at 5:00 AM, Alex Bradbury <asb at lowrisc.org> wrote: > >> This all makes sense to me. > > > > That's correct, thanks for the feedback. > > > > I do like the idea from James of having the compiler always spit out a > > note

# Overview and background RISC-V is a free and open instruction set architecture. It is a modular specification, with a range of standard extensions (e.g. floating point, atomics, etc). New standard extensions are developed through RISC-V Foundation working groups. The specifications for such extensions (e.g. vector and bit manipulation) are publicly available, but are still in flux and won't

On 14 November 2017 at 16:03, Alex Bradbury <asb at lowrisc.org> wrote: > Dear list, > > At the RISC-V BoF at the LLVM Dev Meeting and the longer working > session the day after, those of us working on RISC-V with LLVM decided > it would be worthwhile to schedule regular sync-up calls in order to > better co-ordinate ongoing work between different developers. This is >

# RFC: Atomic LL/SC loops in LLVM revisited ## Summary This proposal gives a brief overview of the challenges of lowering to LL/SC loops and details the approach I am taking for RISC-V. Beyond getting feedback on that work, my intention is to find consensus on moving other backends towards a similar approach and sharing common code where feasible. Scroll down to 'Questions' for a summary

Dear list, At the RISC-V BoF at the LLVM Dev Meeting and the longer working session the day after, those of us working on RISC-V with LLVM decided it would be worthwhile to schedule regular sync-up calls in order to better co-ordinate ongoing work between different developers. This is primarily to sync-up, share blocking issues and so on. I understand something similar was done during the

On Tue, 21 Jan 2020 at 01:14, Chris Lattner <clattner at nondot.org> wrote: > > On Jan 16, 2020, at 10:01 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe code should be committed to LLVM when it is of sufficient > > quality, when it can be shown to benefit the LLVM user or developer > > communities, and when there is someone

On 23 November 2017 at 09:38, Alex Bradbury <asb at lowrisc.org> wrote: > On 14 November 2017 at 16:03, Alex Bradbury <asb at lowrisc.org> wrote: >> Dear list, >> >> At the RISC-V BoF at the LLVM Dev Meeting and the longer working >> session the day after, those of us working on RISC-V with LLVM decided >> it would be worthwhile to schedule regular

As many of you know, I have a growing series of patches for a RISC-V backend under/awaiting review <https://reviews.llvm.org/differential/?authors=asb&order=updated>, <http://github.com/lowrisc/riscv-llvm>. I'll be posting a larger status update on that work either later today or tomorrow, this RFC focuses on an issue that came up during review which I think may benefit from

On 18 August 2016 at 15:21, Renato Golin <renato.golin at linaro.org> wrote: > On 18 August 2016 at 14:32, Alex Bradbury <asb at asbradbury.org> wrote: >> 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

Oh, I wasn’t really thinking about devices without an MMU where the addresses are physically separated. Makes sense. This reminds me of rwpi on ARM; it has a sort of similar scheme of referring to data indirectly through a pointer, but it also changes the ABI to keep the pointer in a reserved register. -Eli From: Evandro Menezes <evandro.menezes at sifive.com> Sent: Friday, March 20, 2020

There will be a RISC-V focused Birds of a Feather (BoF) session at the LLVM Dev Meeting in a few weeks time <https://2017llvmdevmtg.sched.com/event/CMiv/co-ordinating-risc-v-development-in-llvm> (Wednesday, October 18, 4:20pm - 5:05pm) The aim of this session is to bring together everyone with an interest in RISC-V support LLVM, and especially those from companies who have had private

Alex, ping? There was a thread about moving Risc-V out of experimental but I think it didn't go anywhere? Separately, do the listed patches sound okay for merging? Thanks, Hans On Fri, Jan 25, 2019 at 4:40 PM Bruce Hoult <brucehoult at sifive.com> wrote: > > In https://llvm.org/svn/llvm-project/llvm/branches/release_80 I find > that RISCV is still in

Hello, James, Thank you very much for your advices! The next step in compiler development on Espressif is object file generation. There are no essential problems with this step, it will be implemented in nearest future. Currently Xtensa backend is able to print and parse assembly, I used about 1300 tests from gcc torture testsuite and GNU binutils to debug assembly output and now all tests

For background on these calls, see <http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html>. Reminder: the purpose is to co-ordinate between active contributors. If you have support questions etc then it's best to post to llvm-dev. We have a call every alternate Thursday at 4pm GMT, via <https://meet.google.com/ske-zcog-spp>. We have a shared calendar which may help

If I’m following correctly, there are two size-limited areas. One area, limited to 2GB, is the “text” area. This contains all the code. Then there’s a “global” area, limited to 4GB, which is pointed to by the global pointer. This contains the GOT, plus a flexible area that the object file can stick small bits of data into. And then outside of both of those, additional data is unlimited. It