<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Mon, Feb 4, 2019, 03:46 Simon Moll <<a href="mailto:moll@cs.uni-saarland.de" target="_blank" rel="noreferrer">moll@cs.uni-saarland.de</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-5910852678530459921m_-7256771533039963037moz-cite-prefix">On 2/2/19 1:39 AM, Luke Kenneth Casson
Leighton wrote:<br>
</div>
<blockquote type="cite">
<br>
<br>
On Friday, February 1, 2019, Simon Moll <<a href="mailto:moll@cs.uni-saarland.de" rel="noreferrer noreferrer" target="_blank">moll@cs.uni-saarland.de</a>>
wrote:
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="auto"> </div>
</blockquote>
<p>We could untie the mask length from the data length:</p>
<p> %result = call <scalable 4 x float>
@llvm.evl.fsub.v4f32(<scalable 4 x float> %x,
<scalable 4 x float> %y, <scalable 1 x i1> %M,
i32 %L)</p>
<p>would then indicate the mask %M applies to groups of "4 /
1" float elements.</p>
</div>
</blockquote>
<div><br>
</div>
<div>That would provide the greatest flexibility, as a 1:1 ratio
could mean 1 bit per element, covering the normal case.</div>
<div><br>
</div>
<div>Question: are there any circumstances under which it is
desirable to underspecify or overspecify the number of bits in
the predicate?</div>
<div><br>
</div>
<div>ie to deliberately have a FP vector of length 11 and a mask
of length 9 or 13?</div>
</blockquote>
<p>You are referring to the sub-vector sizes, if i am understanding
correctly. I'd assume that the mask sub-vector length always has
to be either 1 or the same as the data sub-vector length.</p></div></blockquote></div></div><div dir="auto">I think that allowing the mask sub-vector length to be any divisor of the data sub-vector length will allow the most flexible instructions, enabling scalable vectors to be emulated by fixed-length simd operations more easily, simplifying frontends. I don't think non-divisible lengths should be allowed.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p> For
example, this is ok:</p>
<p> %result = call <scalable 3 x float>
@llvm.evl.fsub.v4f32(<scalable 3 x float> %x, <scalable 3
x float> %y, <scalable 1 x i1> %M, i32 %L)</p>
<p> %result = call <scalable 5 x float>
@llvm.evl.fsub.v4f32(<scalable 5 x float> %x, <scalable 5
x float> %y, <scalable 1 x i1> %M, i32 %L)</p>
<p> %result = call <16 x float> @llvm.evl.fsub.v4f32(<16
x float> %x, <4 x float> %y, <4 x i1> %M, i32 %L)</p>
<p>This is invalid IR:</p>
<p> %result = call <scalable 4 x float>
@llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4
x float> %y, <scalable 2 x i1> %M, i32 %L)</p>
<p> %result = call <scalable 11 x float>
@llvm.evl.fsub.v4f32(<scalable 11 x float> %x, <scalable
11 x float> %y, <scalable 9 x i1> %M, i32 %L)</p>
<p> %result = call <5 x float> @llvm.evl.fsub.v4f32(<5 x
float> %x, <5 x float> %y, <7 x i1> %M, i32 %L)</p>
<p><br>
</p>
<p>In case you are talking about the dynamic vector length (eg what
happens if the dynamic length's don't match at runtime), i think
the key here is to regard the vector length parameter "vlen %L" as
a contract: the semantics of the EVL operation is undefined if the
runtime lengths of the vectors are shorter than indicated by %L.
That is the mask has a minimum element count of %L * mask
sub-vector length, the data has a minimum element count of %L *
data sub-vector length.<br>
</p>
<p>- Simon<br>
</p>
<blockquote type="cite">
<div><br>
</div>
<div>Or, is that just a runtime error.</div>
<div><br>
</div>
<div>L.</div>
<br>
<br>
-- <br>
---<br>
crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" rel="noreferrer noreferrer" target="_blank">https://www.crowdsupply.com/eoma68</a><br>
<br>
</blockquote>
<pre class="m_-5910852678530459921m_-7256771533039963037moz-signature" cols="72">--
Simon Moll
Researcher / PhD Student
Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.31
Tel. +49 (0)681 302-57521 : <a class="m_-5910852678530459921m_-7256771533039963037moz-txt-link-abbreviated" href="mailto:moll@cs.uni-saarland.de" rel="noreferrer noreferrer" target="_blank">moll@cs.uni-saarland.de</a>
Fax. +49 (0)681 302-3065 : <a class="m_-5910852678530459921m_-7256771533039963037moz-txt-link-freetext" href="http://compilers.cs.uni-saarland.de/people/moll" rel="noreferrer noreferrer" target="_blank">http://compilers.cs.uni-saarland.de/people/moll</a></pre>
</div>
</blockquote></div></div></div>