search for: setvl

...tor >> registers when there's less than a full register worth of data remaining. SVE uses >> predication (masking) to achieve the same effect. >> >> For the 'V' extension, vscale would indeed correspond to 'maxvl', and I'm hoping that a >> 'setvl' intrinsic that provides a predicate will avoid the need for modelling a change in >> dynamic vector length -- reducing the vector length is effectively equivalent to an implied >> predicate on all operations. This avoids needing to add a token operand to all existing >> instr...

...and unlike the scalable variant that's not > even useful) and it would be the sole legal vector types in the RISCV > backend. > >> >>>> For the 'V' extension, vscale would indeed correspond to 'maxvl', and I'm hoping that a >>>> 'setvl' intrinsic that provides a predicate will avoid the need for modelling a change in >>>> dynamic vector length -- reducing the vector length is effectively equivalent to an implied >>>> predicate on all operations. This avoids needing to add a token operand to all existin...

...form the last iterations of a loop within vector registers when there's less than a full register worth of data remaining. SVE uses predication (masking) to achieve the same effect. For the 'V' extension, vscale would indeed correspond to 'maxvl', and I'm hoping that a 'setvl' intrinsic that provides a predicate will avoid the need for modelling a change in dynamic vector length -- reducing the vector length is effectively equivalent to an implied predicate on all operations. This avoids needing to add a token operand to all existing instructions that work on vector...

...give one example, "speculative" loads (which silencing > some exceptions to safely permit vectorization of some loops with > data-dependent exits, such as strlen) can shrink vl as a side effect. > I believe this can be handled by modelling all relevant operations > (including setvl itself) as intrinsics that have side effects or > read/write inaccessible memory. However, if you want to have the > "current" vl (or equivalent mask) around as SSA value, you need to > "reload" it after any operation that updates vl. That seems like it > could get a...

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

...irection table that can arbitrarily redirect the 32 registers to 64 REAL registers (64 real FP and 64 real int), including empowering Compressed instructions to access the full 64 registers, even when the C instruction is restricted to x8-x15. Predication similarly is via CSR redirection/lookups. SETVL is slightly different from RV as it requires an immediate length as an additional parameter. This because the Maximum Vector Length is no longer hardcoded into silicon, it instead specifies exactly how *many* contiguous registers in the standard regfile need to be used, NOT how many are in a totall...

...all-true mask is free. So for VE, the %evl does all the predication and there is no reason to have anything other than a (splat i1 1) %mask here. On SVE/MVE you may want to use get.active.lane.mask instead and on RISC-V V, AFAIU, the %evl parameter will have to be computed by some RISC-V specific `setvl` intrinsic. Both of this is okay because VP gives you that flexibility. I am not sure why MVE (or AVX) would need the vscale(). But if it does, I am wondering if it could be something like: ; RISC-V V & VE(*): ; %mask = get.active.lane.mask(%i, %i) ; %evl = call @llvm.vscale(256, %n...

...all-true mask is free. So for VE, the %evl does all the predication and there is no reason to have anything other than a (splat i1 1) %mask here. On SVE/MVE you may want to use get.active.lane.mask instead and on RISC-V V, AFAIU, the %evl parameter will have to be computed by some RISC-V specific `setvl` intrinsic. Both of this is okay because VP gives you that flexibility. I am not sure why MVE (or AVX) would need the vscale(). But if it does, I am wondering if it could be something like: ; RISC-V V & VE(*): ; %mask = get.active.lane.mask(%i, %i) ; %evl = call @llvm.vscale(256, %n...

...t > six or twelve months as it's gotten closer to being set in stone. > > The way it has ended up (very unlikely to change now) is: > > - any given RVV vector unit has 32 registers each with the same and > fixed length in bits. > > - the vector unit is configured by the VSETVL[I] instruction which has > two arguments: 1) the requested AVL, and 2) the vtype (vector type). > > - The vtype is an integer with several small fields, of which two are > currently defined (the other bits must be zero). The fields are the > Standard Element Width and VLMul. SEW can...

...ently, it would be much, much better to be able to have a > > single bit of a predicate apply to the *entire* vec3 or vec4 type, on > > each outer loop. > > This situation can be handled easily in the standard RISC-V vector > extension. You'd do something like... > > vsetvli t0, a0, vsew128,vnreg8,vdiv4 > > ... to configure the vector unit to provide eight vector register > variables divided into a standard element width of 128 bits (some > instructions will widen or narrow one step to/from 64 bits or 256 > bits), and then dividing each 128 bit element...

On 11/6/20 8:49 AM, Roger Ferrer Ibáñez wrote: Hi Sjoerd, Trying to remember how everything fits together here, but could get.active.lane.mask not create the %mask of the VP intrinsics? Or in other words, in the vectoriser, who's producing the %mask and %evl that is consumed by the VP intrinsics? I'm not sure what would be the best way here. I think about the Loop Vectorizer. I imagine

Hi David, Thanks for taking a look. > On 5 Jun 2018, at 16:23, dag at cray.com wrote: > > Hi Graham, > > Just a few initial comments. > > Graham Hunter <Graham.Hunter at arm.com> writes: > >> ``<scalable x 4 x i32>`` and ``<scalable x 8 x i16>`` have the same number of >> bytes. > > "scalable" instead of "scalable

Hi, Now that Sander has committed enough MC support for SVE, here's an updated RFC for variable length vector support with a set of 14 patches (listed at the end) to demonstrate code generation for SVE using the extensions proposed in the RFC. I have some ideas about how to support RISC-V's upcoming extension alongside SVE; I'll send an email with some additional comments on