search for: getvl

Hi David, Let me put the last two comments up: > > But we're trying to represent slightly different techniques > > (predication, vscale change) which need to be tied down to only > > exactly what they do. > > Wouldn't intrinsics to change vscale do exactly that? You're right. I've been using the same overloaded term and this is probably what caused the

...anges aren't always on the last iteration. The Cray X1 had an > instruction (I would have to dust off old manuals to remember the > mnemonic) with somewhat strange semantics to get the desired VL for an > iteration. Code would look something like this: > > loop top: > vl = getvl N # N contains the number of iterations left > <do computation> > N = N - vl > branch N > 0, loop top > > The "getvl" instruction would usually return the full hardware vector > register length (MAXVL), except on the 2nd-to-last iteration if N was &g...

...e expensive and should be rare anyway. ; explicit vlen_state modelling in RV could look like this: @vlen_state=thread_local globaltoken ; this gives AA a fixed point to constraint vlen-dependent operations llvm.vla.setvl(i32 %n)                  ; implicitly writes-only %vlen_state i32 llvm.vla.getvl()                    ; implicitly reads-only %vlen_state llvm.vla.fadd.f64(f64, f64)           ; implicitly reads-only %vlen_state llvm.vla.fdiv.f64(f64, f64)           : .. same ; this implements the "speculative" load mentioned in the quote above (writes %vlen_state. I suppose it als...

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