<br><br>On Wednesday, October 2, 2019, Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net">lkcl@lkcl.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Wednesday, October 2, 2019, Robin Kruppe <<a href="mailto:robin.kruppe@gmail.com" target="_blank">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"><br></div></div></blockquote><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><div><br></div><div>Ok so taking the RISCV developers off cc, because it looks like neither SV nor RVV would use vscale, as we basically identified, eventually, that it is a way to express the "architectural SIMD width".</div><div><br></div><div>The rest of this is therefore nothing to do with vector engines, and is purely some constructive input for future consideration.</div><div><br></div><div>Let us take a scenario where data is short vectors, well below vscale. That there is also some inter-element dependence (cross product or other) which makes laying multiple short vectors into a single vscale long SIMD awkward.</div><div><br></div><div>Under such circumstances having a fixed vscale is extremely wasteful, particularly if there is an out of order engine which could use mixed scalar or MMX/SSE with AVX512 for example.</div><div><br></div><div>Thus for the longer operations the idea is to throw those at AVX512 and the shorter ones at 64 bit MMX/SSE.</div><div><br></div><div>The point is: *both could benefit from vscale* excrpt unfortunately, there is only *one* vscale and it can therefore only be applied to *one* of the SIMD ALUs.</div><div><br></div><div>This tends to suggest that either vscale should be a variable (and applicable on a per group basis, separated by LD/STs)</div><div><br></div><div>OR</div><div><br></div><div>That there should be more than one vscale.</div><div><br></div><div>i.e that vscale should, instead.of being a fixed global type, should instead be morphed to be %vscaleN similar to %regN, conveying the context of its intended scope and use.</div><div><br></div><div>Thus, certain groups of operations intended to be farmed to a SPECIFIC SIMD suite (AVX512) may be *specifically* separated from those intended to be targetted at another suite (MMX/SSE).</div><div><br></div><div>Of course, on architectures which have no such distinction, a simple pass would merge them all into one global vscale.</div><div><br></div><div>A thought for consideration.</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>