<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Mon, Feb 4, 2019, 15:32 Robin Kruppe via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> wrote:<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 dir="ltr" class="gmail_attr">On Mon, 4 Feb 2019 at 23:04, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><br>
    <p>On NEC SX-Aurora the vector length is always interpreted in 64bit
      data chunks. That is one example of a real architecture where the
      vscaled interpretation of VL makes sense.<br></p></div></blockquote><div>Now this is a problem. Let's leave the details of why RISC-V V needs the other interpretation to Phab, but we definitely have a conflict in what these two architectures need. How do we reconcile them? Picking one option and requiring a multiplication/division of the vlen argument to get the other meaning is a nice canonical IR form, but it seems a bit problematic for codegen because that mul/div is a prime candicate for being CSE'd across blocks (pure calculation, repeated everywhere) and consequently being difficult to access for pattern matching in the backend.</div><div><br></div><div>On the other hand, it's a less serious problem than was previously discussed re: vlen vs predication. The actual change in codegen is just omitting one instruction, which one can easily do that in an SSA-based MIR pass if necessary (instead of during ISel). Moreover, the cost of a missed folding opportunity is relatively minor, since it'll most likely be just a shift by an immediate, and it'll usually be amortized over basically the entire loop body in a lot of code.</div></div></div></blockquote></div></div><div dir="auto">It's minor for power-of-2 subvector sizes. Our ISA supports subvectors of size 3, and division by 3 is much more complex. Also, the code we will be generating will have a lot of subvectors of size 3 since they are used wherever a 3d position (basically at least a few times in each shader) or normal vector is used.</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 dir="ltr"><div class="gmail_quote"><div><br></div><div>Still, does anyone have a better idea?</div><div><br></div><div>Cheers,</div><div>Robin<br></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>