<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 04/23/2015 07:42 AM, James Molloy
      wrote:<br>
    </div>
    <blockquote
cite="mid:CALCTSA0H9cVTB5SpS0b3-d6jNLV4jE0bhjrNgX2yFkeWufw-Cw@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi all,
        <div><br>
        </div>
        <div>I've just started again on trying to solve the problem of
          getting decent code generation for min, max and abs idioms as
          used by the programmer and as emitted by the loop vectorizer.</div>
        <div><br>
        </div>
        <div>I've been looking at doing this as a target DAGCombine, but
          actually I think:</div>
        <div>  1. it's incredibly complex to do at that stage and it
          limits all the work I do to just one target.</div>
        <div>  2. It's also much more difficult to test.</div>
        <div>  3. The loop and SLP vectorizers still don't have a cost
          model for them - they're just seen as compare+selects.</div>
      </div>
    </blockquote>
    I don't see the challenge here.  Matching a compare+select as a
    min/max for the purpose of the cost model under a target specific
    hook seems quite straightforward.  What am I missing?<br>
    <br>
    <blockquote
cite="mid:CALCTSA0H9cVTB5SpS0b3-d6jNLV4jE0bhjrNgX2yFkeWufw-Cw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>So my proposal is:</div>
        <div>  * To add new intrinsics for minimum, maximum and absolute
          value. These would have signed int/unsigned int/float variants
          and be valid across all numeric types.</div>
        <div>  * To add a pass fairly early in the pipeline to idiom
          recognize and create intrinsics. This would be controllable
          per-backend - if a backend doesn't have efficient lowering for
          these operations, perhaps it's best not to do the idiom
          recognition.</div>
      </div>
    </blockquote>
    I am strongly opposed to this part of the proposal.  I have no
    problem* adding such intrinsics and matching them late (i.e.
    CodeGenPrep), but I am deeply concerned about the negative impacts
    of matching early.  Unless you are volunteering to add support for
    these intrinsics to *every* pass, I believe doing this is a
    non-starter.  As a good example, consider what happened recently
    with the x.with.overflow intrinsics where we were missing important
    simplifications on induction variable dependent checks due to early
    canonicalization to a form that the rest of the optimizer didn't
    understand.  <br>
    <br>
    More generally, I'm not even sure matching these early would be the
    right answer even if you were volunteering to update the entire
    optimizer.  Being able to fold the condition (CSE, etc..)
    independently of the select and then being able to exploit a
    dominating branch is extremely powerful at eliminating the min/max
    operation entirely.  I would be deeply concerned about giving up
    that power without an incredible compelling reason. <br>
    <br>
    * By "no problem", I really mean that I have no opinion here.  I am
    neither endorsing nor opposing.  <br>
    <blockquote
cite="mid:CALCTSA0H9cVTB5SpS0b3-d6jNLV4jE0bhjrNgX2yFkeWufw-Cw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>The cost model would then fall out in the wash, because we
          already have a cost model for intrinsics, it would be as
          simple as adding new instructions. </div>
      </div>
    </blockquote>
    <br>
    <blockquote
cite="mid:CALCTSA0H9cVTB5SpS0b3-d6jNLV4jE0bhjrNgX2yFkeWufw-Cw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Because we idiom recognize at the IR stage instead of the
          SDAG stage, we also wouldn't have to rely on the min/max
          idioms being in canonical "select" form; we could match a
          branch sequence also.</div>
      </div>
    </blockquote>
    Er, not sure I get your point here.  Not having to match two
    distinct families of representation is an advantage, not a
    disadvantage.  The branch form should be getting converted into the
    select form much earlier in the optimizer.  Which cases are you
    worried about here?<br>
    <blockquote
cite="mid:CALCTSA0H9cVTB5SpS0b3-d6jNLV4jE0bhjrNgX2yFkeWufw-Cw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>What do you think? Is this an acceptable proposal?</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div><br>
        </div>
        <div>James</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>