<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">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><br></div><div>Still, does anyone have a better idea?</div><div><br></div><div>Cheers,</div><div>Robin<br></div></div></div>