search for: rvv

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 to run a few more times on > lower spec'd h...

...ttention to Stephen's questions and it becomes clear: https://groups.google.com/forum/?nomobile=true#!topic/comp.arch/3z3PlCwdq8U A link to ARM SVE ffirst capability is also proved in that thread. Yes, SVE has ffirst although it is a SIMD variant rather than one that affects VL. > RISC-V RVV explicitly allows changing VL (which I am assuming is the > same as vscale) at runtime, so VL wouldn't be a constant. This would be good to clarify, Sander. On first reading it seems to me that vscale is intended to be the actual full vector size, not related to VL. Regardless, setting it...

On Tue, Oct 1, 2019 at 8:08 AM Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hello Jacob and Luke, > > First off, even if a dynamically changing vscale was truly necessary > for RVV or SV, this thread would be far too late to raise the question. > That vscale is constant -- that the number of elements in a scalable > vector does not change during program execution -- is baked into the > accepted scalable vector type proposal from top to bottom and in fact > was one...

...tor at runtime, not the number of currently active elements. ok, this starts to narrow down the definition. i'm attempting to get clarity on what it means. so, in the example above involving globalvec, "maximum size of the vector at runtime" would be "1024" (not involving RVV VL). and... would vscale would be dynamically (but permanently) substituted with the constant "1024", there? and in that example i gave which was a local function, vscale would be substituted with "local_vlen_param_len" permanently and irrevocably at runtime? or, is it intend...

...well as Vector-based "Maximum Vector Length", typically representing > the "Lanes" of a [traditional] Vector Architecture. > >> 2. Vectors of changing size throughout the program. > > ...representing VL in "Cray-style" Vector Engines (NEC SX-Aurora, RVV, > SV) and representing the (rather unfortunate) corner-case cleanup - > and predication - deployed in SIMD > (https://www.sigarch.org/simd-instructions-considered-harmful/) > >> Where (2) basically builds on (1). >> >> LLVM's scalable vectors support (1) directl...

...oes having it as part of the EVL intrinsics > work? 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 re-configured per function (RVV only atm) - (heavy weight, stop-the-world instruction). The vectorlen parameter in EVL intrinsics is for the AVL. >> >> I'm curious what SVE will do if there is an if/then/else in the middle >> of a vectorised loop with a shorter-than-maximum vector length. You >> can&...

...t;> 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 re-configured per >> function (RVV only atm) - (heavy weight, stop-the-world instruction). >> >> The vectorlen parameter in EVL intrinsics is for the AVL. > Unless I misunderstand, this doesn't describe RVV correctly, although > this is understandable as the spec has moved around a bit in the last > six or t...

I've posted two patches on Phabricator to add support for VScale in LLVM. A brief recap on `vscale`: The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to create types such as `<vscale x 16 x i8>` for a scalable vector with at least 16 bytes. In the definition of the scalable type, `vscale` is specified as a positive constant of type integer that will only be

...Hunter <Graham.Hunter at arm.com> wrote: > > Hi Luke, > >> On 1 Oct 2019, at 09:21, Luke Kenneth Casson Leighton via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>> First off, even if a dynamically changing vscale was truly necessary >>> for RVV or SV, this thread would be far too late to raise the question. >>> That vscale is constant -- that the number of elements in a scalable >>> vector does not change during program execution -- is baked into the >>> accepted scalable vector type proposal from top to bottom...

Hi Robin, responses inline. -Graham > On 11 Jun 2018, at 16:47, Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hi Graham, > Hi David, > > glad to hear other people are thinking about RVV codegen! > > On 7 June 2018 at 18:10, Graham Hunter <Graham.Hunter at arm.com> wrote: >> >> Hi, >> >>> On 6 Jun 2018, at 17:36, David A. Greene <dag at cray.com> wrote: >>> >>> Graham Hunter via llvm-dev <llvm-dev at lists.llvm.o...

...b/1?cid=bG93cmlzYy5vcmdfMG41cGtlc2ZqY25wMGJoNWhwczFwMGJkODBAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ> * <https://calendar.google.com/calendar/ical/lowrisc.org_0n5pkesfjcnp0bh5hps1p0bd80%40group.calendar.google.com/public/basic.ics> Issues to discuss today include the following: * Non-scalable RVV support (Fraser) * Patches we might want to discuss: * Zfh (D90738) * Setrounding/flt_rounds lowering * PrologEpilogInserter floating emergency spill slots (D89239) * Any bitmanip patches people want to discuss? * Other: * Heads up on https://github.com/riscv/riscv-elf-psabi-doc/issues/16...

...normally in every other way that we use it. The PBX still functions, outbound manual calls still function, inbound calls, voicemail, nothing else appears to be negatively impacted. However new files introduced into /var/spool/asterisk/outgoing/ folder get ignored. No messages spring up on asterisk -rvv console, nothing shows up in the logs, the .call files just get snubbed. We're at a loss to determine what other debugging avenues may be available, and we have googled for every applicable keyword we can think of including "asterisk auto dial" and "pbx_spool" to no avail....

On Fri, Mar 15, 2019 at 1:55 PM Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 3/15/19 10:58 AM, David Greene wrote: >> > Renato Golin <rengolin at gmail.com> writes: >> > >> >> On Fri, 15 Mar 2019 at

...y adds a variable length concept. 2. With there being absolutely no new instructions whatsoever (standard existing AND FUTURE scalar ops are instead made implicitly parallel), and given the deliberate design similarities it seems to me that SV would be a good first experimental backend *ahead* of RVV, for which the 240+ opcodes have not yet been finalised. Would people concur? 3. If there are existing patches, where can they be found? 4. From Jeff Bush's Nyuzi work It has been noted that certain 3D operations are just far too expensive to do as SIMD or vectors. Multiple FP ARGB to 24/32 b...

...sensus in exploring this approach > instead of the VLA approach. > >> Without context, it's hard to know what's going on. > > The current state is just what you stated in your initial email in this > chain; we have a solution that seems to work (in principal) for SVE, RVV, > and SX-Aurora, but not enough people that care about VLA vectorization > beyond those groups. > > Given the time constraints, Arm is being pushed to consider a plan B to > get something working in time for early 2020. > > -Graham > > > > > ______________...

...sion 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 of the talk (April 2019) LLVM support for the V extension was developed out-of-tree at https://github.com/hanna-kruppe/rvv-llvm . However, that repository is archived now and the README file indicates that it is outdated since support 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...

Hi, > On 6 Jun 2018, at 17:36, David A. Greene <dag at cray.com> wrote: > > Graham Hunter via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> Ok, now I understand what you're getting at. A ConstantExpr would >>> encapsulate this computation. We alreay have "non-static-constant" >>> values for ConstantExpr like sizeof and

...o scan for certain kinds of vector operations and add the special attribute, or just always add this special attribute, and that just becomes another special case, which will only actually manifest on certain platforms, that it's best to avoid. > > Modelling the dynamic vector length for RVV is something for Robin (or others) to tackle later, but can be though of (at a high level) as an implicit predicate on all operations. My point is that, while there may be some sense in which the details can be worked out later, we need to have a good-enough understanding of how this will work now...

On Wed, 13 Mar 2019 at 13:57, Graham Hunter <Graham.Hunter at arm.com> wrote: > I did ask them to post their arguments on the list, but I guess they've been busy for the last month (or forgot about it). Who is "them" and who will write up a proposal / RFC on the use of intrinsics for both lowering and vectorisation? It goes without saying that those discussions should have

...> instead of the VLA approach. > >> > >>> Without context, it's hard to know what's going on. > >> The current state is just what you stated in your initial email in this > >> chain; we have a solution that seems to work (in principal) for SVE, > RVV, > >> and SX-Aurora, but not enough people that care about VLA vectorization > >> beyond those groups. > >> > >> Given the time constraints, Arm is being pushed to consider a plan B to > >> get something working in time for early 2020. > >> >...