<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Aug 29, 2019 at 9:00 AM Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Thu, 29 Aug 2019 at 13:27, Graham Hunter via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> 1) Add a new SPLAT_VECTOR ISD node. This was part of our overall RFC from 2016 and is the solution that we're currently using downstream. It just accepts a single scalar value. This has worked well with just the SVE codegen using it, but I don't know if we would run into problems if we try to make this the canonical splat form for SDAG.<br>
><br>
> 2) Extend BUILD_VECTOR to accept an initial boolean indicating whether it is a splat, and if true the first element can be assumed to be the same as all others. The splat form would be the only valid use of BUILD_VECTOR for scalable vector types. For fixed length vectors we could either change existing checks for splats to only look at the flag and would only need one extra argument for the splat value, or use the flag as a shortcut and fall back to checking all the elements if there's the possibility of a fold generating a splat and it not being recognised.<br>
<br>
Hi Graham,<br>
<br>
I'm not a big fan of boolean flags on related concepts because the API<br>
becomes brittle. In this case, BUILD_VECTOR-splat would need an assert<br>
to make sure there's only one element.<br></blockquote><div><br></div><div>Agreed. #1 is better.</div><div><br></div><div>The Complex proposal requires special uses of broadcasts. Hopefully someone from that project can comment here. It would be nice to design Complex support into SPLAT_VECTOR, so that special lowerings aren't needed.</div></div></div></div></div>