search for: risc

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 f...

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...

Hello Everyone, for a small embedded System i would like to install CentOS, but it is a RISC System. So my Question is it possible to rebuild some SRPMs for RISC? Thanks in Advance Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil UR...

Hi all, I am currently compiling R to RISC-V64 CPU and I think I have discovered a NA propagation failure. How R implements NA (not available) and NaN (not-a-number) is explained in detail here: https://stat.ethz.ch/pipermail/r-devel/2014-February/068380.html. In short, according to my understanding of R's convention, any calculation...

...actually mean? Is the architecture MIPS? Or the producer? When I go to Wikipedia I see MIPS as the designer, so I take it is like saying "Intel CPU" or "AMD CPU" but that does not tell me anything about the assembly instruction it uses, right? But then also I see as Design "RISC", as I understood it describes the assembly instructions? But why would I tell Clang to target "mips1" when the design of the R3000 is RISC? Why isn't RISCV correct then? Or RISC1 or so... Also how does that influence floating point arithmetic? I often heard that those are separ...

Hi Devs, since risc-v has a register $tp which is thread pointer. is it possible to have __builtin_thread_pointer for RISC-V? I am not sure what could be corresponding instructions? ./kamlesh

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...

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 betwee...

On 11/6/20 12:39 PM, Sjoerd Meijer wrote: Hello Simon, Thanks for your replies, very useful. And yes, thanks for the example and making the target differences clear: ; Some examples: ; RISC-V V & VE(*): ; %mask = (splat i1 1) ; %evl = min(256, %n - %i) ; MVE/SVE : ; %mask = get.active.lane.mask(%i, %n) ; %evl = call @llvm.vscale() ; AVX: ; %mask = icmp (%i + (seq <8 x i32> 0,1,2,.,)), %n, ; %evl = i32 8 Unless I miss something, the AVX example is s...

Hello, I'm using rsync on RISC-V machines. I notice that the developers of rsync seem to assume that only x86 CPUs can handle memory misalignments: ```c /* We know that the x86 can handle misalignment and has the same ?* byte order (LSB-first) as the 32-bit numbers we transmit. */ #if defined __i386__ || defined __i486__ || d...

; RISC-V V & VE(*): ; %mask = get.active.lane.mask(%i, %i) ; %evl = min(256, %n - %i) ; MVE/SVE/AVX : ; %mask = get.active.lane.mask(%i, %n) ; %evl = call @llvm.vscale() For VE, we want to do as much predication as possible through %evl and as little as possible with %mask. This has...

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...

# 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 mani...

...ed 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

Hi Everyone, I am wondering how to use RISC-V V (Vector) extension instructions in LLVM IR. In 2019 Kruppe and Espasa gave a talk [1] overviewing the Vector extension and on slide 16 [2] they show LLVM IR samples which use the vector instructions through intrinsic functions, such as: %vl = call i32 @llvm.riscv.vsetvl(i32 %n) At the time...

...ng. VPred IR needs two additional operands, as you mentioned, %evl and %mask. One option is make %evl the max-vector-length of the type being operated and %mask (that is the "outer block mask" in this context) be get.active.lane.mask. This maps well for SVE and MVE not so much for VE and RISC-V (I don't think it is incorrect but it is not an efficient thing to do). Perhaps VE and RISC-V can work in this scenario if at some point they replace the %evl with something like "%n - %base" operands of get.active.lane.mask, and %mask (the outer block mask) is replaced with a spla...

...clang from source, a github clone from today: clang version 11.0.0 (https://github.com/llvm/llvm-project.git 91aa67bf290bc7f877b1b90128284863bc31aa43) I compiled a small program: #include <stdint.h> int main() { uint8_t a = 2; uint8_t b = 5; uint8_t c = a * b; } $ clang -c -target riscv32 -march=rv32imc -g main.c Works fine. The dumped assembly seems to not know about the multiply instruction - is that expected? See offset 1e in the listing below. Happily, the opcode value does appear to match the MUL instruction. $ llvm-objdump -S main.o main.o: file format ELF32-riscv Disa...

Hello Simon, Thanks for your replies, very useful. And yes, thanks for the example and making the target differences clear: ; Some examples: ; RISC-V V & VE(*): ; %mask = (splat i1 1) ; %evl = min(256, %n - %i) ; MVE/SVE : ; %mask = get.active.lane.mask(%i, %n) ; %evl = call @llvm.vscale() ; AVX: ; %mask = icmp (%i + (seq <8 x i32> 0,1,2,.,)), %n, ; %evl = i32 8 Unless I miss something, the AVX example is s...

Hey everyone, I would like to add my graduate paper to the list of LLVM publications: http://scholarworks.rit.edu/theses/9550/ Here's the abstract if anyone is interested: *The Design of a Custom 32-bit RISC CPU and LLVM Compiler Backend* Compiler infrastructures are often an area of high interest for research. > As the necessity for digital information and technology increases, so does > the need for an increase in the performance of digital hardware. The main > component in most complex dig...

...Trunk LLVM does not contain support for code generating the V extension yet. The experimental-v support you see there is only MC-layer support, where you can use the V instructions in assembly (including inline assembly). There is currently (today) no way of turning LLVM IR vector intrinsics into RISC-V V extension instructions. Hanna Kruppe did have a fork of LLVM where she and others were working on prototype support for the V extension. The work on support for the V extension has continued, but not via upstreaming the exact changes in that prototype - instead there is an RFC about code gener...