<br><br>On Wednesday, October 2, 2019, Robin Kruppe <<a href="mailto:robin.kruppe@gmail.com">robin.kruppe@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, 2 Oct 2019 at 05:09, Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net" target="_blank">lkcl@lkcl.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div><div>My general feeling on this then is that both RVV and SV should avoid using vscale.</div><div><br></div><div>In the case of RVV, MVL is a hardware defined constant that is never *intended* to be known by applications. There's no published detection mechanism.  Loops are supposed to be designed to run a few more times on lower spec'd hardware.</div><div><br></div><div>Robin, what's your thoughts there?</div></div></blockquote><div><br></div><div>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, </div></div></div></blockquote><div><br></div><div>Ah excellent. It's a little obtuse (the wording is very indirect. As the RVV WG is a closed list, can I leave it with you to raise that as an issue?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>which is directly related to VLEN (so you can obtain VLEN with a little more arithmetic, though for most purposes VLMAX is more useful): requesting the vector length of -1 (unsigned: 2^XLEN - 1) is guaranteed to result in vl=VLMAX.<br></div><div><br></div><div>For regular strip-mined loops, the vsetvl instruction takes care of everything so there's simply no need for the program to do this. But for other tasks, it's required (i.e., you can't sensibly write the program otherwise) and perfectly fine w.r.t. portability. One example is the stack frame layout when there's any vectors on the stack (e.g. for spills), since the vector stack slots must in general be large enough to hold a full vector (= VLEN*LMUL bits). </div></div></div></blockquote><div><br></div><div>Kernel context switch as well. Both would likely be written in assembler.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Granted, I don't think this or other examples will normally occur in LLVM IR generated by a loop vectorizer, so vscale will probably not occur very frequently in RVV. </div></div></div></blockquote><div><br></div><div>Interesting. It is sort-of what I had a hunch would be the case.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Nevertheless, there is nothing inherently non-portable about it.<br></div></div></div></blockquote><div><br></div><div>Indeed.  Thank you for the insights, Robin.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Regards</div><div>Robin<br></div><div><br></div><div>PS: I don't want to read too much into your repeated use of "MVL", but FWIW the design of RVV has changed quite radically since "MVL" was last used in any spec draft. If you haven't read any version since v0.6 (~ December 2018) with a "clean slate", may I suggest you do that when you find the time? You can find the latest draft at <a href="https://github.com/riscv/riscv-v-spec/" target="_blank">https://github.com/riscv/<wbr>riscv-v-spec/</a><br></div></div></div></blockquote><div><br></div><div>Ah yes thank you, I reference it at least three times a week: such a large document it is easy to miss things. I will replace MVL in SV with VLMAX.</div><div><br></div><div>Appreciated the headsup.</div><div><br></div><div>L.</div><div><br></div><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>