<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 7/24/19 7:42 AM, John McCall wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:AABA47A3-DAEA-41DB-B5E0-E9A55BF15E1A@apple.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div style="font-family:sans-serif">
        <div style="white-space:normal">
          <p dir="auto">On 24 Jul 2019, at 1:46, Philip Reames wrote:</p>
        </div>
        <div style="white-space:normal">
          <blockquote style="border-left:2px solid #777; color:#777;
            margin:0 0 5px; padding-left:5px">
            <p dir="auto">We've also got some cases where returning a
              value in a flag might be useful.  Our typical use case is
              we have a "rare, but not *that* rare* slowpath which
              sometimes needs to run after a call from a runtime
              function.  Our other compiler(s) - which use hand rolled
              assembly for all of these bits - return the "take-rare"
              bit in ZF, and branch on that after the call.  For our
              LLVM based system, we just materialize the value into $rax
              and branch on that.  That naive scheme has been
              surprisingly not bad performance wise.<br>
              <br>
              * The "not *that* rare" part is needed to avoid having
              exceptional unwinding be the right answer.<br>
              <br>
              If we were to support something like this, you'd really
              want to be able to define individual flags in the callee's
              calling convention clobber/preserve lists.  It's really
              common to have a helper routine which sets say ZF, but
              leaves others unchanged.  Or to have a function which sets
              ZF, clobbers OF, and preserves all others.  But if we were
              going to do that, we'd quickly realize that the x86
              backend doesn't track individual flags at all, and thus
              conclude it probably wasn't worth it begin with.  :)</p>
          </blockquote>
        </div>
        <div style="white-space:normal">
          <p dir="auto">I'm intrigued what functions would usefully <em>preserve</em>
            flags. That's quite difficult on x86, since it means you
            have to spill flags if you do any basic arithmetic at all
            (unless you do it all with <code
              style="background-color:#F7F7F7; border-radius:3px;
              margin:0; padding:0 0.4em" bgcolor="#F7F7F7">lea</code>).
            Maybe on a target like PPC with really fleshed-out support
            for flags and conditionality?</p>
        </div>
      </div>
    </blockquote>
    <p>My use case would be hand written assembly stubs for particular
      fastpath operations.  These aren't compiler generated, and the
      hour of human time to line of code ratio is quite high.  Having
      said that, while I have practical examples where returning flags
      have been used, I don't, off the top of my head, have a concrete
      example of needing to preserve flags (except DF).  So, take that
      part more as a "if we're there anyways, the ideal would be...". 
      On a practical level, return via flags with full clobber (except
      DF) would probably be more than sufficient.</p>
    <p>* On every x86 abi I know of, the direction flag (DF) is assumed
      to be preserved through a call.  Messing with it and forgetting to
      reset it results in "interesting and unpleasant" bugs.  <br>
    </p>
    <p>Philip<br>
    </p>
    <p>p.s. Has anyone played with lowering a switch via sahf and a
      series of jccs to dispatch?  It occurs to me that given all the
      combo variants of jccs, you could probably lower many switches on
      4 bit values this way.  Purely asking as a fun thought experiment,
      nothing more.  <br>
    </p>
  </body>
</html>