search for: bradburi

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

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

> > Hello CCrb users. > > Is there a way to configure Cruise Control rb to only build one > project at a time? > > I have two projects is two different repositories, and I don''t want > their builds to overlap. > > Thanks, > > Doug Bradbury > Software Craftsman > 8th Light, Inc. > blog.8thlight.com/doug

armando at mail.bpa.cu The original message was received at Thu, 26 Nov 2009 08:39:46 -0500 from faraon.cgr.bpa.cu [172.16.24.98] ----- The following addresses had permanent fatal errors ----- <armando at mail.bpa.cu> (reason: 554 5.4.6 Too many hops) ----- Transcript of session follows ----- 554 5.4.6 Too many hops 27 (25 max): from <christopher.chan at bradbury.edu.hk>

On Mon, Aug 28, 2017 at 8:04 AM, Alex Bradbury <asb at asbradbury.org> wrote: > On 27 August 2017 at 00:01, Alex Bradbury <asb at asbradbury.org> wrote: >> Hi all. I'm assuming most people reading this email are familiar with LLVM's >> code review process <http://llvm.org/docs/DeveloperPolicy.html#code-reviews> >> as well as LLVM Weekly, the

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

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

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

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

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,

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

On 11 May 2014 13:25, Alex Bradbury <asb at asbradbury.org> wrote: > On 6 May 2014 09:42, Jay Foad <jay.foad at gmail.com> wrote: >> I followed a link from LLVM Weekly to http://reviews.llvm.org/rL207598 and got: >> >> " >> Still Importing... >> >> This commit is still importing. Changes will be visible once the >> import finishes.

> On 4 Jan 2018, at 10:51, Alex Bradbury <asb at lowrisc.org> wrote: > > On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I haven't dug into the GlobalISel calling convention code much but I can comment on the

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 30 Jan 2018, at 19:56, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is this bad style? It seems the current codebase is inconsistent on > this point. The upside of such duplication is that it reduces the need > to cross-reference to other files when using a dumb editor. I generally use the rendered docs on the LLVM web site when using a dumb editor, so

# 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

LLVM Weekly - #189, Aug 14th 2017 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/189>. Welcome to the one hundred and eighty-ninth 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

I just want to say that I really, really, appreciate the information given on this site: http://qaweb.dev.centos.org/qa/calendar -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax:

On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. Thanks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool