<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Performing vectorization in the SelectionDAG tends to be fraught
      with problems as we don't have a cost model mechanism to control
      it; we hit this in <a class="moz-txt-link-freetext" href="https://bugs.llvm.org/show_bug.cgi?id=35732">https://bugs.llvm.org/show_bug.cgi?id=35732</a>
      where conversion ops were being vectorized in DAG whether we
      wanted to or not, purely based on a isOperationLegalOrCustom call
      (just because an op is possible doesn't mean its efficient to do
      so under all circumstances).<br>
    </p>
    <p>In general I think we should be relying on the SLPVectorizer to
      handle this instead. If SLP is failing, we're probably better off
      spending dev time fixing it there instead of trying to cleanup in
      DAG (e.g. too often I find its a case of tweaking the TTI cost
      models).</p>
    <p>Having said that, we do hit cases where vectorizable patterns do
      appear during legalization - x86 does some very limited bitwise op
      vectorization in lowerBuildVectorToBitOp as this was such a common
      occurrence. So there's probably scope to provide some common
      helper functions in SelectionDAG.cpp to recognise vectorizable
      patterns (similar to SelectionDAG::matchBinOpReduction) but we
      leave it up to the target's build_vector combiner/lowering to
      actually decide whether to make use of them.</p>
    <p>Simon.<br>
    </p>
    <div class="moz-cite-prefix">On 10/01/2020 21:49, Nemanja Ivanovic
      via llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAObEeNjZiNVgZUnVebb+mhYYU-A4sK6zxP=kDtKiwRzydh4DPA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>I have added a few PPC-specific DAG combines in the past
          that follow this pattern on specific operations. Now that it
          appears that this would be useful to do on yet another
          operation, I'm wondering what people think about doing this in
          the target-independent DAG Combiner for any legal/custom
          operation on the target.</div>
        <div><br>
        </div>
        <div>TL; DR;</div>
        <div>The generic pattern would look like this:</div>
        <div>
          <pre class="gmail-c-mrkdwn__pre" style="box-sizing:inherit;margin:4px 0px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;border-radius:4px;color:rgb(29,28,29);font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-family:monospace">(build_vector (op (extractelt %a, 0), [(extractelt %b, 0)]...),
              (op (extractelt %a, 1), [(extractelt %b, 1)]...), ...)</span>
</pre>
          <pre class="gmail-c-mrkdwn__pre" style="box-sizing:inherit;margin:4px 0px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;border-radius:4px;color:rgb(29,28,29);font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-family:arial,sans-serif">Basically, if the build vector is built from the same operation applied on elements extracted from another vector (or pair of vectors for binary ops), then we can check for the legality of the operation on the vector type. If the operation is legal for the vector type (and the operand and result vector types are the same), then we can just convert this to
<span style="font-family:monospace">
(op %a [, %b])</span></span></pre>
          <pre class="gmail-c-mrkdwn__pre" style="box-sizing:inherit;margin:4px 0px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;border-radius:4px;color:rgb(29,28,29);font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-family:arial,sans-serif">Which is likely going to produce better code in all cases. Of course, things like this have a tendency to not be better in all cases, but I think we can probably account for any corner cases that arise.

Example:
<span style="font-family:monospace">(v2i64 build_vector (mulhs (extractelt %a, 0), (extractelt %b, 0)),
                    (mulhs (extractelt %a, 1), (extractelt %b, 1)))</span>

Can be converted to the following on a target that has the operation available on vectors.
<span style="font-family:monospace">(v2i64 mulhs %a, %b)</span></span></pre>
          <pre class="gmail-c-mrkdwn__pre" style="box-sizing:inherit;margin:4px 0px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;border-radius:4px;color:rgb(29,28,29);font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-family:arial,sans-serif">A further improvement might be if the order of extracted elements doesn't match the order in the build_vector, that we shuffle one or both input vectors prior to applying the operation.

</span></pre>
          <pre class="gmail-c-mrkdwn__pre" style="box-sizing:inherit;margin:4px 0px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;border-radius:4px;color:rgb(29,28,29);font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-family:arial,sans-serif">If you think this is a good idea (or a terrible idea), please let me know.
</span></pre>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </body>
</html>