search for: rv32

Hi all: I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem when adding soft float routine for rv32, RISC-V ABI required 128 bits bits for long double, but it's implemented by int128_t, however rv32 don't support __int128_t. Of cause, it not hard thing to support __int128_t by overriding TargetInfo::hasInt128Type for LLVM, but its will cause some ABI incompatible with GCC, because GCC do...

On 30 January 2018 at 14:12, Kito Cheng via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all: > > I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem > when adding soft float routine for rv32, RISC-V ABI required 128 bits > bits for long double, but it's implemented by int128_t, however rv32 > don't support __int128_t. > > Of cause, it not hard thing to support __int128_t by overriding > TargetInfo::hasInt128Type for LLVM, but its will cause some ABI > incompat...

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

...s an immediate to define vscale, that implies the value of vscale is known at compile-time and thus regular (fixed-width) vector types can be used? > now, we mmmiiiight be able to get away with assuming that vscale is > equal to the absolute maximum possible setting (64 for RV64, 32 for > RV32), then use / play-with the "runtime active VL get/set" > intrinsics. > > i'm kiinda wary of saying "absolutely yes that's the way forward" for > us, particularly without some input from Jacob here. Note that there isn't a requirement to use `vscale` as p...

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

...tic was added so the static analyzer skips yacc/bison-generated files. [r326135](http://reviews.llvm.org/rL326135). ## Other project commits * Initial PPC64 instruction emulation landed in LLDB. [r326224](http://reviews.llvm.org/rL326224). * Support was added for building compiler-rt for RISC-V RV32 and RV64. [r326420](http://reviews.llvm.org/rL326420). * lld now accepts both `--foo bar` and `--foo=bar` command line option styles. [r326506](http://reviews.llvm.org/rL326506).

Hello everyone, I wanted to attach a node without affecting the present nodes in any way. I tried to use MVT::Glue for that but I think I'm missing something as I could not achieve the below state. LUI LUI | | ADDI ----GLUE---- ADDI | store I've few question about this and Glue node in general, I'll be happy to get some help on

Thanks @Robin and @Graham for giving some background on scalable vectors and clarifying some of the details! Apologies if I'm repeating things here, but it is probably good to emphasize the conceptually different, but complementary models for scalable vectors: 1. Vectors of unknown, but constant size throughout the program. 2. Vectors of changing size throughout the program. Where (2)

On Thu, Jul 11, 2019 at 10:42 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Thu, 11 Jul 2019 at 18:03, Reshabh Sharma <reshabhsh at gmail.com> wrote: > > Ah now I could see it more clearly. I was not sure that should I add > them (MO_LO32_LO and MO_LO32_HI), btw this was backup plan. Probably for > now we are going with this. I implemented them today and

...FC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, the RISC-V backend has i64 as the only legal integer type for the RV64 target. Thanks to variable-sized register class support, this means there is no need for duplication of either patterns or instruction definitions for RV32 and RV64. It's worth noting that RV64I is a different base ISA to RV32I. Rather than adding 64-bit operations, it re-defines the operations as 64-bit and introduces a small number of 'W' suffixed instructions such as ADDW, SLLW etc to operate on 32-bit values. There are some challenges...

Simon Pilgrim <llvm-dev at redking.me.uk> writes: > Changing a test's IR to avoid an issue in a patch is very problematic, > but if any test's codegen changes because of a patch then it just > needs to be reviewed, preferably by someone who has touched that test > in the past. But wouldn't it be even better if that output didn't need to be changed at all and

...upport for the RISC-V V extension is now developed upstream. I assume that this means that the features are now available from LLVM master. However, when I pull the current master and build it and try to compile the sample code with llc (specifying the target with --mtriple=riscv32-unkown-none-rv32imv ), I get following error: error: ../llvm-project/build/bin/llc: test.ll:4:18: error: use of undefined value '@llvm.riscv.vsetvl' It seems that the V extension is available, since `llc -march=riscv32 -mattr=help` lists it: Available features for this target:   ...   experimental-v ...

...ad/draft-20180612-548fd40/riscv-spec.pdf>, which incorporates work from the Memory Consistency Model Task Group to define the memory model. RISC-V implements a weak memory model. For those not familiar, RISC-V is a modular ISA, with standard extensions indicated by single letters. Baseline 'RV32I' or 'RV64I' instruction sets don't support atomic operations beyond fences. However the RV32A and RV64A instruction set extensions introduce AMOs (Atomic Memory Operations) and LR/SC (load-linked/store-conditional on other architectures). 32-bit atomic operations are supported nati...