<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 31, 2018 at 9:13 PM, Renato Golin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Indeed. I have a limited view on the spec and even more so on hardware<br>
implementations, but it is my understanding that there is no attempt<br>
to change VL mid-loop.<br>
<br>
If we can assume VL will be "the same" (not constant) throughout every<br>
self-contained sub-graph (from scalar|memory->vector to<br>
vector->scalar|memory), there we should encode it in the IR spec that<br>
this is a hard requirement.<br></blockquote><div><br></div><div>I don't see any harm in (very occasionally) making the VL shorter somewhere within an iteration of a loop. Some work that was already done will be wasted, but that's not a correctness problem. Making the VL longer mid-iteration would of course be very bad.</div><div><br></div><div>The important thing is that the various source and destination pointers are updated by the correct amount at the end of the loop.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This seems consistent with your explanation of the Cray VL change as<br>
well as Bruce's description of RISC-V (both seem very similar to me),<br>
where VL can change between two loop iterations but not within the<br>
same iteration.<br></blockquote><div><br></div><div>I'm not sure whether it will end up being possible or not, but I did describe two situations where at least some RISC-V implementations might want to change VL within an iteration:</div><div><br></div><div>1) a memory protection problem on some trailing part of a vector load or store, causing that iteration to operate only on the accessible part, and the next iteration to start from the first address in the non-accessible part (and actually take a fault)</div><div><br></div><div>2) an interrupt/task switch in the middle of a loop iteration. Some implementations may want to save/restore only the vector configuration, not the values of the vector registers.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I don't see why predicate values would be affected at all.  If a machine<br>
> with variable vector length has predicates, then typically the resulting<br>
> operation would operate on the bitwise AND of the predicate and a<br>
> conceptual all 1's predicate of length VL.<br>
<br>
</span>I think the problem is that SVE is fully predicated and Cray (RISC-V?)<br>
is not, so mixing the two could lead into weird predication<br>
situations.<br></blockquote><div><br></div><div>The current RISC-V proposal has a 2-bit field in each vector instruction, with the values indicating:</div><div><br></div><div>- it's actually scalar</div><div>- vector operation with no predication</div><div>- vector operation, masked by the predicate register</div><div>- vector operation, masked by the inverse of the predicate register</div><div><br></div></div></div></div>