<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 10/23/13 10:03 PM, Andrew Trick
      wrote:<br>
    </div>
    <blockquote
      cite="mid:304D65E6-4BC5-4CBF-97B7-4F715447D7FA@apple.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On Oct 23, 2013, at 7:26 PM, Philip Reames <<a
            moz-do-not-send="true"
            href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <meta content="text/html; charset=windows-1252"
            http-equiv="Content-Type">
          <div bgcolor="#FFFFFF" text="#000000">
            <div class="moz-cite-prefix">On 10/23/13 5:38 PM, Andrew
              Trick wrote:<br>
            </div>
            <blockquote
              cite="mid:1DB87D5C-C4BA-49AD-9D99-1A30990745CA@apple.com"
              type="cite">
              <meta http-equiv="Content-Type" content="text/html;
                charset=windows-1252">
              <br>
              <div>
                <div>On Oct 23, 2013, at 5:27 PM, Philip Reames <<a
                    moz-do-not-send="true"
                    href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>

                  wrote:</div>
                <br class="Apple-interchange-newline">
                <blockquote type="cite">
                  <div bgcolor="#FFFFFF" text="#000000">
                    <blockquote
                      cite="mid:FE120C63-E4BE-433C-A416-2B75DC3FC566@apple.com"
                      type="cite" style="font-family: Helvetica;
                      font-size: 12px; font-style: normal; font-variant:
                      normal; font-weight: normal; letter-spacing:
                      normal; line-height: normal; orphans: auto;
                      text-align: start; text-indent: 0px;
                      text-transform: none; white-space: normal; widows:
                      auto; word-spacing: 0px;
                      -webkit-text-stroke-width: 0px;">The
                      implementation of the two intrinsics is actually
                      very similar. In this case, the difference would
                      be that llvm.stackmap does not reserve space for
                      patching, while llvm.patchpoint does.</blockquote>
                    <span style="font-family: Helvetica; font-size:
                      12px; font-style: normal; font-variant: normal;
                      font-weight: normal; letter-spacing: normal;
                      line-height: normal; orphans: auto; text-align:
                      start; text-indent: 0px; text-transform: none;
                      white-space: normal; widows: auto; word-spacing:
                      0px; -webkit-text-stroke-width: 0px;
                      background-color: rgb(255, 255, 255); float: none;
                      display: inline !important;">I'm slightly confused
                      by this given that stackmap takes an argument
                      indicating the number of nops to emit as well, but
                      it's not worth debating this any more.  Let's move
                      on.  We can revisit this once I'm actually using
                      the new intrinsics and can provide real concrete
                      feedback. <span class="Apple-converted-space"> </span></span></div>
                </blockquote>
              </div>
              <div><br>
              </div>
              I want this to be clear when we expose the intrinsics to
              other developers. I’ve been making an effort to improve
              the docs: <a moz-do-not-send="true"
                href="http://llvm-reviews.chandlerc.com/D1981">http://llvm-reviews.chandlerc.com/D1981</a>.
              Please let me know where clarification is needed</blockquote>
            I responded in the review.  The only big thing that might be
            worth discussion here is the "full resume" semantics which
            are mentioned at the very end.  This seemed to disagree with
            our previous discussion.  Let me know if you're either a)
            unclear at what I was getting at or b) believe the "full
            resume" semantics were a key part of the intrinsic.  In
            either case, we should probably hash it out here.  <br>
          </div>
        </blockquote>
      </div>
      <br>
      <div>Thanks for the review. I'll respond to each of your comments
        there.</div>
      <div><br>
      </div>
      <div>There's one important thing I'm not getting across.
        llvm.stackmap is not primarily intended for patching. As an
        additional feature, llvm.stackmap can specify the size of its
        shadow, but does not need to generate nops in its shadow. The
        shadow can contain arbitrary code from the same function. The
        only purpose of the shadow is to allow destructive patching.
        Destructive means that other that some arbitrary code may be
        overwritten. I think the only use for this is to invalidate
        compiled code in a way that allows the runtime to recover. That
        just happens to be a very important use. Note that if we didn't
        specify a shadow, the runtime would have a hard time knowing how
        to patch without potentially clobbering something outside the
        current function.</div>
    </blockquote>
    So essentially you're using the shadow region to enable creating
    either a nop sled which carries you down into deopt code or a forced
    trap (i.e. patching with an instruction sequence which forces a trap
    to a signal handler)?  Ok, that sounds reasonable.  You should spell
    this out this example explicitly in the documentation.  It's useful
    for clarification purposes.<br>
    <br>
    Yours,<br>
    Philip<br>
    <br>
    <br>
    <br>
  </body>
</html>