similar to: [riscv] How do I use the RISC-V Vector extension instructions in LLVM IR?

Michael, Apologies for taking so long to get back to you. 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

On 2/5/19 1:27 AM, Philip Reames via llvm-dev wrote: > > On 1/31/19 4:57 PM, Bruce Hoult wrote: >> On Thu, Jan 31, 2019 at 4:05 PM Philip Reames via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> Do such architectures frequently have arithmetic operations on the >>> mask registers?  (i.e. can I reasonable compute a conservative >>> length

On Wed, 2 Oct 2019 at 05:09, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote: > > My general feeling on this then is that both RVV and SV should avoid using > vscale. > > In the case of RVV, MVL is a hardware defined constant that is never > *intended* to be known by applications. There's no published detection > mechanism. Loops are supposed to be designed

I am using LLVM version 4.0.1 Running `llc -march=riscv64 math.ll` returns: #0 0x0000000000fed7d1 (llc+0xfed7d1) #1 0x0000000000fec559 (llc+0xfec559) #2 0x0000000000fec8d9 (llc+0xfec8d9) #3 0x00007f22c044e5e0 __restore_rt (/lib64/libpthread.so.0+0xf5e0) #4 0x0000000000d7faf3 (llc+0xd7faf3) #5 0x0000000000cd4b88 (llc+0xcd4b88) #6 0x0000000000cd530c (llc+0xcd530c) #7 0x00000000006858c3

*llvm-project version:dd8a2013dc1804be1b7d9cffacad2e984300bd22* *Instructons to build LLVM+clang:* ``` cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/home/llvm/workspace/llvm/llvm-project/llvm_install -DCMAKE_BUILD_TYPE="Release" -DDEFAULT_SYSROOT="/home/llvm/workspace/riscv/riscv-tc-20200220/bin/riscv32-unknown-elf"

Hi, I am not sure if this is the right forum. Please direct me to the appropriate place if it isn't so. Please keep in CC as i am not subscribed to this mailing list. I am trying to test riscv llvm tools in QEMU using llvm testsuite. As a trial i am trying only the Single Source C Regression folder. The steps that i took are : ]$ cmake -DCMAKE_C_COMPILER=/opt/riscv-tools/bin/clang

I am using llvm-project compiling risc-v programs. llvm-project version:dd8a2013dc1804be1b7d9cffacad2e984300bd22 Instructons to build LLVM+clang: ``` cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/home/llvm/workspace/llvm/llvm-project/llvm_install -DCMAKE_BUILD_TYPE="Release" -DDEFAULT_SYSROOT="/home/llvm/workspace/riscv/riscv-tc-20200220/bin/riscv32-unknown-elf"

On 27 November 2016 at 16:51, Amara Emerson <amara.emerson at gmail.com> wrote: > There is nothing to stop other targets from using > stepvector/seriesvector. In fact for wide vector targets, often the IR > constant for representing a step vector is explicitly expressed as > <i32 0, i32 1, i32 2..> and so on (this gets really cumbersome when > your vector length is

I built llvm + 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

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > We're in-progress designing a RISC-V extension (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x

# 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

Hi all developers, I'm changing compiler from gcc to llvm on a RISCV target now. but I found in some case the assembly code generated by llvm is much more than gcc. It cause my program's performance about 40% decrease. The flowing is a simple test code. It shows the problem. We can see than gcc prefer to use pointer to iterate the array, but llvm perfere to use index to iterate

On 28 November 2016 at 09:15, Alex Bradbury <asb at asbradbury.org> wrote: > The RISC-V vector proposal is still in the development stage, but it > will inevitably be vector length agnostic much like Hwacha. Krste gave > a talk about his proposal for the 'V' extension last year > <https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf> >

On Fri, Feb 1, 2019 at 1:19 AM Bruce Hoult <brucehoult at sifive.com> wrote: > On Thu, Jan 31, 2019 at 11:53 PM Luke Kenneth Casson Leighton via > llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > --- > > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > > On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay

has anyone in this list ever tried to make a javascript color picker something like http://www.daantje.nl/blog/index.php?buttonID=37 or http://typetester.maratz.com/ i just thought i''d ask before i force myself to doing this. thanks mark renn _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org

On 2/5/19 12:06 PM, Bruce Hoult wrote: > On Tue, Feb 5, 2019 at 1:23 AM Simon Moll <moll at cs.uni-saarland.de> wrote: >> I think this is the usual mixup of AVL and MVL. >> >> AVL: is part of the predicate and can change between vector operations >> just like a mask can (light weight). >> >> MVL: Is the physical vector register length and can be

Hi all, I'm currently working on the implementation for LLVM of the RISCV Bit Manipulation ISA extension described by Clifford Wolf in the following presentation: https://content.riscv.org/wp-content/uploads/2019/06/17.10-b_wolf.pdf and the following document: https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-0.90.pdf The aim is to provide the intrinsic functions to the user in

On 13 April 2018 at 16:52, Robin Kruppe <robin.kruppe at gmail.com> wrote: > On 13 April 2018 at 14:37, Graham Hunter <Graham.Hunter at arm.com> wrote: > >> Hi, >> >> Nice to see another group tackling length agnostic vectorization :) >> >> I'm still reading through all the details, but I do have one initial >> question related to the

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic

Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches. And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing first like the LV