search for: vlmax

...houghts there? > Software should be portable across different RVV implementations, in particular across different values of the impl-defined constants VLEN, ELEN, SLEN. But being portable does not mean software must never mention these (and derived quantities such as vscale or, in the RVV spec, VLMAX) at all, just that it has to work correctly no matter which value they have. And in fact, there is a published (written out in the spec) mechanism for obtaining VLMAX, which is directly related to VLEN (so you can obtain VLEN with a little more arithmetic, though for most purposes VLMAX is more use...

...block boundary. But it is NOT the case that you can computer the active vector length VL from an initial mask value. The active vector length is set by the hardware based on the remaining application vector length. The VL can change for each loop iteration -- the normal pattern is for VL to equal VLMAX for initial executions of the loop, and then be less than VLMAX for the final one or two iterations of the loop. For example if VLMAX is 16 and there are 19 elements left in the application vector then the hardware might choose to use 10 elements for the 2nd to last iteration and 9 elements for the...

Hi Luke, > was it intentional to leave out both jacob and myself? > [...] > if that was a misunderstanding or an oversight i apologise for raising it. It was definitely not my intention to be non-inclusive, my apologies if that seemed the case! > can i therefore recommend a change, here: > [...] > "This patch adds vscale as a symbolic constant to the IR, similar to >

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote: > On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I've posted two patches on Phabricator to add support for VScale in LLVM. Excellent! > > > > A brief recap on `vscale`: > > The scalable vector type in

...case that you can computer the active vector length >> VL from an initial mask value. The active vector length is set by the >> hardware based on the remaining application vector length. The VL can >> change for each loop iteration -- the normal pattern is for VL to >> equal VLMAX for initial executions of the loop, and then be less than >> VLMAX for the final one or two iterations of the loop. For example if >> VLMAX is 16 and there are 19 elements left in the application vector >> then the hardware might choose to use 10 elements for the 2nd to last >&...

On Thu, 31 Jan 2019 at 20:17, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 1/31/19 11:03 AM, David Greene wrote: > > Philip Reames <listmail at philipreames.com> writes: > > > >> Question 1 - Why do we need separate mask and lengths? Can't the > >> length be easily folded into the mask operand? > >> >

Hi, There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy