<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2/2/19 1:39 AM, Luke Kenneth Casson
      Leighton wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPweEDxfD3tnY0H+4h0trebB1GCQSs0AUAzX6ZVTJ4W-hLOHGw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <br>
      <br>
      On Friday, February 1, 2019, Simon Moll <<a
        href="mailto:moll@cs.uni-saarland.de" moz-do-not-send="true">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. 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"
cite="mid:CAPweEDxfD3tnY0H+4h0trebB1GCQSs0AUAzX6ZVTJ4W-hLOHGw@mail.gmail.com">
      <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" target="_blank"
        moz-do-not-send="true">https://www.crowdsupply.com/eoma68</a><br>
      <br>
    </blockquote>
    <pre class="moz-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="moz-txt-link-abbreviated" href="mailto:moll@cs.uni-saarland.de">moll@cs.uni-saarland.de</a>
Fax. +49 (0)681 302-3065  : <a class="moz-txt-link-freetext" href="http://compilers.cs.uni-saarland.de/people/moll">http://compilers.cs.uni-saarland.de/people/moll</a></pre>
  </body>
</html>