<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>When working on a couple of recent changes in SCEV, I stumbled on
      a couple of gaps around how we optimize the @llvm.umin
      intrinsics.  If I remember correctly, we added these because they
      needed different poison propagation semantics than select, and
      that memory triggered a thought.  <br>
    </p>
    <p>I want to raise the question of whether we should support both
      possible poison propagation semantics for the select instruction. 
      As a brief review, the two options are:</p>
    <ol>
      <li>Poison propagates only through the selected operand.  e.g.
        "select i1 true, i32 0, i32 poison" is not poison.  <br>
      </li>
      <li>Poison propagates if any operand is poison.  e.g. "select i1
        true, i32 0, i32 poison" is poison.  </li>
    </ol>
    <p>Each of the two options has advantages.  This was discussed in
      depth a while ago, and we'd picked (1).  I don't want to reopen
      that discussion; I want to raise the question of whether we should
      pick "both".  <br>
    </p>
    <p>If we were to add a flag "npo" (for "no poison operand",
      bikeshedding welcome!) to the select instruction, we could
      represent both options.  This has a couple of advantages:</p>
    <ul>
      <li>We can lower all of the umin/etc.. intrinsics to selects and
        avoid having to duplicate folds.  This  would reduce the
        combinatoric space for pattern matching optimizations.  This
        would probably help optimization results in practice.  <br>
      </li>
      <li>We can restore many of the removed select->arithmetic folds
        (only for the npo selects).</li>
      <li>We can infer npo flag on a select in many cases.  (e.g.
        "select i1 %c, i32 0, i32 57" can be trivially converted to
        "select npo i1 %c, i32 0, i32 57")  This also allows us to
        factor logic into testable pieces whereas current transforms
        which are npo dependent must include the no-poison inference.<br>
      </li>
    </ul>
    <p>The major downside is that transformation code would have to be
      careful to only apply transforms dependent on "no poison operand"
      if the flag is set.</p>
    <p>Anyways, I don't have time to actually work on this, so I'm
      mostly throwing out the idea in case anyone with time and
      motivation finds it interesting to pursue.</p>
    <p>Philip<br>
    </p>
  </body>
</html>