similar to: RISC-V LLVM sync-up conference calls

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 >

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

On 21 March 2018 at 20:07, Alex Bradbury <asb at lowrisc.org> wrote: > 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,

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

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

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

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

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

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

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 each Thursday at 4pm GMT, via <https://meet.google.com/ske-zcog-spp>. I've created a shared calendar which may help

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

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

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

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

LLVM Weekly - #52, Dec 29th 2014 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/52>. Welcome to the fifty-second issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org).

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

# 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

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

LLVM Weekly - #57, Feb 2nd 2015 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/57>. Welcome to the fifty-seventh issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org).

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 BST, via <https://meet.google.com/ske-zcog-spp>. We have created a shared calendar which