<div dir="ltr"><div>Hello Jacob and Luke,</div><div><br></div><div>
<div></div><div>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 of the conditions for its acceptance (runtime-variable type sizes create many more headaches which nobody has worked out how to solve to a satisfactory degree in the context of LLVM). *This* thread is just about whether vscale should be exposed to programs in the form of a Constant or as an intrinsic which always returns the same value during one program execution.</div>

</div><div><br></div><div>Luckily, this is not a problem for RVV. I do not know anything about this "SV" extension you are working on so I cannot comment on that, but I'll sketch the reasons for why it's not an issue with RVV and maybe that helps you with SV too. As mentioned above, this is tangential to the focus of this thread, so if you want to discuss further I'd prefer you do that in a new thread.<br></div><div><br></div><div>The dynamically-changing VL is a kind of predication in that it limits processing to a subset of lanes, and like masks it can just be another SSA value that is an input to the computations it affects. You may be aware of Simon Moll's vector predication  (previously: explicit vector length) proposal which does just that. In contrast, the vscale concept is more about how many elements a vector register contains, regardless of whether some operations process only a subset of them. In RVV terms that means it's related not to VL but more to VBITS, which is indeed a constant (and has been for many months).<br></div><div><br></div><div>The only dynamic thing about "how many elements are there in a vector register" is that varying the width of the elements (8b, 16b, etc.) and the length multiplier (grouping together 1/2/4/8 registers) causes a predictable, relative increase or decrease 
(x2, x8, x0.5, etc.)  of the number of elements, regardless of the specific value of VBITS. But this is perfectly compatible with a constant vscale because vscale only is the unknown-at-compile-time *factor* in the size of a scalable vector type. Varying the other components, the compile-time-constant factor and the element type, results in scalable vectors with different *relative* sizes in exactly the same way we need to handle RVV's element width and LMUL concepts. For example <vscale x 4 x i16> has four times as many elements and twice as many bits as <vscale x 1 x i32>, so it captures the distinction between a SEW=16,LMUL=2 vtype setting and a SEW=32,LMUL=1 vtype setting.<br></div><div><br></div><div>Regards,</div><div>Robin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 30 Sep 2019 at 23:53, Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net" target="_blank">lkcl@lkcl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>On Tuesday, October 1, 2019, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com" target="_blank">programmerjake@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I've posted two patches on Phabricator to add support for VScale in LLVM.</blockquote><div><br></div><div>Excellent!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> A brief recap on `vscale`:<br>
> 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 known at runtime but is guaranteed to be constant throughout the program.</blockquote><div><br></div><div>Ah.  Right.  There is something known as data-dependent fail-on-first, which does not match with the assertion that vscale will be constant.</div><div><br></div><div>Yes any given vector would be vscale long and it is good to be able to runtime declare such vectors: loops in assembler may be generated which sets VL (a Control Status Register declaring the number of elements to be processed in any given loop iteration)</div><div><br></div><div>However for e.g memcpy or strcpy or anything else which is *not* fixed length and not even the program knows how long the vector will be, there is data-dependent fail-on-first.</div><div><br></div><div>A related thread goes through this, pay attention to Stephen's questions and it becomes clear:</div><div><a href="https://groups.google.com/forum/?nomobile=true#!topic/comp.arch/3z3PlCwdq8U" target="_blank">https://groups.google.com/forum/?nomobile=true#!topic/comp.arch/3z3PlCwdq8U</a><br></div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
RISC-V RVV explicitly allows changing VL (which I am assuming is the<br>
same as vscale) at runtime, so VL wouldn't be a constant.</blockquote><div><br></div><div>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.</div><div><br></div><div>Regardless, setting it even as *runtime* constant seems to be a red flag.</div><div><br></div><div>What is vscale intended for, and how does it relate to Cray-like Vector Length?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Additionally, we (libre-riscv) are working on a similar scalar vectors<br>
ISA called SimpleV that also allows changing VL at runtime and we are<br>
planning on basing it on LLVM's scalable vector support.</blockquote><div><br></div><div>Both SV and RVV are based on Cray VL which is a runtime global CSR setting the number of elements to be processed in any given vector loop.</div><div><br></div><div>The difference is that RVV *requests* a VL and is arbitrarily *allocated* an actual VL (less than or equal to the requested VL), where in SV you get exactly what is requested and if overallocated an illegal instruction is raised.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> [1] <a href="https://reviews.llvm.org/D68202" target="_blank">https://reviews.llvm.org/D68202</a><br>
> [2] <a href="https://reviews.llvm.org/D68203" target="_blank">https://reviews.llvm.org/D68203</a><br>
<br>
Jacob Lifshay<br>
</blockquote><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>
</blockquote></div>