<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>OpenVMS' non-call exception support on Alpha & Itanium does
      have some restrictions.  We'll do some study and attempt to
      address the concerns when I post the doc next week.</p>
    <p>However, our primary focus is precise exception modelling in the
      prologue/epilogue of routines.  You need precise info on the
      register saves, stack pointer save/restore, etc. that the unwinder
      can use.  On OpenVMS, we don't invoke a routine's personality
      routine if we're in the prologue but the prologue isn't finished. 
      We go up a frame and start searching there.  This level of support
      is needed in our system code (C and BLISS) as well in customer
      code in Fortran, Pascal, BASIC, COBOL, etc.</p>
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 1/19/18 2:27 PM, Reid Kleckner
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CACs=tyKe8JzsdzyVvRG-ncbnsJRLOM-cBDHsnofkY0nA+Ze6WQ@mail.gmail.com">
      <div dir="ltr">I think it's valuable to have precise /
        asynchronous unwind information without adding support for
        non-call exceptions. Profilers and debuggers need to be able to
        unwind the stack from arbitrary instruction boundaries, but they
        don't need to run exception handlers. We can still declare that
        outside the model. Speaking of which, barring bugs, we do
        support precise unwind info on Win64.
        <div><br>
        </div>
        <div>Even if we were to support non-call exceptions, we would
          enumerate the set of supported potentially trapping operations
          that we support, i.e. load, store, div, FP ops, etc. The edges
          would either be explicit, as they are today, or implicit. We
          already have implicit unwind edges out of the function from
          non-nounwind calls, so this isn't as crazy as it sounds.</div>
        <div><br>
        </div>
        <div>We would definitely say that ADDs, PHIs, and other things
          don't trap, so in your example it wouldn't matter if the value
          of 'i' was 1 or 0 if the exception gets raised at 'b'. There
          would be no control-dependent, possibly-unwinding instruction,
          either unwinding to the caller or choosing to run the catch
          handler would be correct. It's equivalent to the asynchronous
          exception arriving a little sooner or a little later, which
          the outside observer has no way to control.</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Jan 19, 2018 at 7:06 AM, David
          Chisnall via llvm-dev <span dir="ltr"><<a
              href="mailto:llvm-dev@lists.llvm.org" target="_blank"
              moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class="">On 19 Jan 2018, at 14:48, John Reagan via
              llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"
                moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
              wrote:<br>
              ><br>
              > OpenVMS' EH model is for full asynchronous
              prologue/epilogue EH.  We do more<br>
              > than just program-level EH, but have to deal with OS
              events (timers going off,<br>
              > asynch I/O completion, mailboxes filled with data,
              etc.) which could result in<br>
              > an unwind occurring.<br>
              ><br>
              > We're just about finished with our proposal for
              extending the x86 compact EH data<br>
              > format to cover all the cases plus the desire to
              create the additional .cfi directives.<br>
              > Feedback and pointers will be most helpful.  Look for
              this as a new thread sometime<br>
              > early next week (we're having our final review on
              Monday before I post it).<br>
              <br>
            </span>Are you planning on extending LLVM to add support for
            non-call exceptions?  Currently, LLVM is not able to produce
            correct unwind tables for arbitrary exception points because
            it does not split basic blocks in such a way that values
            that are created in a basic block will be visible in at the
            end.  For example, if I do<br>
            <br>
            int i = 0;<br>
            try {<br>
              i++;<br>
              foo();<br>
              i++;<br>
            } catch (…) {<br>
              return i;<br>
            }<br>
            <br>
            The SSA form of this will look something more like this:<br>
            <br>
            int i0 = 0;<br>
            try {<br>
              i1 = 1;<br>
              foo();<br>
              i2 = 2;<br>
            } catch (…) {<br>
              return 1;<br>
            }<br>
            <br>
            But if you are allowed to throw exceptions on any
            instruction, then you end up with something more like:<br>
            <br>
            int i0 = 0;<br>
            try {<br>
            a:<br>
              i1 = 1;<br>
            b:<br>
              foo();<br>
            c:<br>
              i2 = 2;<br>
            } catch (…) {<br>
              return phi({a,0},{b, i1},{c,i2});<br>
            }<br>
            <br>
            With the current structure of LLVM’s exception handling, the
            fact that i may be incremented after the only invoke
            instruction is not visible.<br>
            <br>
            I’ve never been entirely happy with how LLVM models
            exceptions, as calls with two possible returns, but
            extending that model to properly support unwinds through
            arbitrary instructions will leave us in the degenerate case
            of having single-instruction basic blocks.  I’d much rather
            that we split blocks on places where values visible in an
            exception handler change, rather than on specific places
            where exceptions are known to be thrown, but this will
            require moving to a region-based representation of
            exceptions, which is a lot of work.  Without this, it’s easy
            to unwind from arbitrary exceptions, unless you care about
            having the right values in your handlers.<br>
            <br>
            David<br>
            <div class="HOEnZb">
              <div class="h5"><br>
                ______________________________<wbr>_________________<br>
                LLVM Developers mailing list<br>
                <a href="mailto:llvm-dev@lists.llvm.org"
                  moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
                <a
                  href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
                  rel="noreferrer" target="_blank"
                  moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>