<br><br>On Tuesday, October 1, 2019, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">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:0 0 0 .8ex;border-left:1px #ccc solid;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">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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> [1] <a href="https://reviews.llvm.org/D68202" target="_blank">https://reviews.llvm.org/<wbr>D68202</a><br>
> [2] <a href="https://reviews.llvm.org/D68203" target="_blank">https://reviews.llvm.org/<wbr>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>