<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Kavindu,</p>
    <p>If it would help, I'm more than happy to jump on a call and walk
      you through some of the basics of the statepoint infrastructure. 
      I frequently find conversation much easier for this type of thing
      than email.</p>
    <p>Philip<br>
    </p>
    <div class="moz-cite-prefix">On 5/7/21 9:23 AM, Kavindu Gimhan Zoysa
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CALoJghU61_q7ZiiHCE_6ScP4Um7gm91SJDUXzHrc4BJ4xndtKg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hi David and Philip,
        <div><br>
        </div>
        <div>Thank you for your responses. The reason to ask that
          question is that, in this <a
            href="https://releases.llvm.org/11.0.0/docs/Statepoints.html"
            moz-do-not-send="true">statepoints document</a>, examples
          are used address space 1. </div>
        <div><br>
        </div>
        <div>I would be grateful if you can check this mail thread "<b>Generate
            statepoints for given code" </b>which was sent by me<b>.</b><br>
        </div>
        <div><br>
        </div>
        <div>Thank you,</div>
        <div>Kavindu</div>
        <div><br clear="all">
          <div>
            <div dir="ltr" class="gmail_signature"
              data-smartmail="gmail_signature">
              <div dir="ltr">
                <div dir="ltr">
                  <div dir="ltr">
                    <div dir="ltr">
                      <div>Kavindu Gimhan Zoysa,</div>
                      <div>BSc(Hons) | ENTC | UoM,<br>
                      </div>
                      <div dir="ltr">SSE | WSO2
                        <div><br>
                        </div>
                        <div><a href="https://github.com/KavinduZoysa"
                            target="_blank" moz-do-not-send="true">GitHub</a> <a
href="https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/"
                            target="_blank" moz-do-not-send="true">LinkedIn</a> <a
href="https://medium.com/@kavindugimhanzoysa" target="_blank"
                            moz-do-not-send="true">Medium</a></div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
          <br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, 7 May 2021 at 21:03,
          Philip Reames via llvm-dev <<a
            href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Point
          of order, most of this work was done to support a Java
          frontend.  <br>
          CLR came later.  :)<br>
          <br>
          David, your point isn't wrong, but it does miss one of the
          major use <br>
          cases.  We support both an abstract machine model and a
          physical machine <br>
          model.  In the abstract machine model, objects aren't
          deallocated.  <br>
          RS4GC is the lowering pass which converts from abstract to
          physical <br>
          (e.g. exposes the existence of deallocation).  In the abstract
          model, we <br>
          need pointers to be "non-integral" to restrict transformations
          which <br>
          would break the reference to object abstraction.<br>
          <br>
          Kavindu, if you're lowering directly to physical (e.g.
          generating <br>
          statepoints in your frontend), you shouldn't care about
          non-integral <br>
          pointers.<br>
          <br>
          Philip<br>
          <br>
          On 5/7/21 8:21 AM, David Chisnall via llvm-dev wrote:<br>
          > Hi,<br>
          ><br>
          > I'm not sure that this is a requirement.  The CLR
          implementation that <br>
          > drove a lot of this work wanted to be able to track both
          native-code <br>
          > pointers that were not GC'd and pointers to the GC'd heap
          and so used <br>
          > AS 1 for GC'd pointers.  If you don't have this
          distinction then you <br>
          > may be able to avoid it.  Note that the data layout makes
          a <br>
          > distinction at the address-space level between pointers
          that can be <br>
          > treated as integers and ones that can't. Pointers to
          memory with <br>
          > accurate GC shouldn't be treated as integers (where they
          may go <br>
          > out-of-bounds in an intermediate state and be lost to the
          GC).<br>
          ><br>
          > David<br>
          ><br>
          > On 07/05/2021 15:28, Kavindu Gimhan Zoysa via llvm-dev
          wrote:<br>
          >> Hi all,<br>
          >><br>
          >> When we generate an LLVM IR introducing statepoints,
          do we <br>
          >> essentially need to use a different address space
          other than the <br>
          >> default address space? If so can you explain the
          reason for that?<br>
          >><br>
          >> Thank you in advance,<br>
          >> Kavindu<br>
          >><br>
          >> Kavindu Gimhan Zoysa,<br>
          >> BSc(Hons) | ENTC | UoM,<br>
          >> SSE | WSO2<br>
          >><br>
          >> GitHub <<a href="https://github.com/KavinduZoysa"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/KavinduZoysa</a>>
          LinkedIn <br>
          >> <<a
            href="https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/</a>>
          Medium <br>
          >> <<a href="https://medium.com/@kavindugimhanzoysa"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://medium.com/@kavindugimhanzoysa</a>><br>
          >><br>
          >> _______________________________________________<br>
          >> LLVM Developers mailing list<br>
          >> <a href="mailto:llvm-dev@lists.llvm.org"
            target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
          >> <a
            href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
          >><br>
          > _______________________________________________<br>
          > LLVM Developers mailing list<br>
          > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
            moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
          > <a
            href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
          _______________________________________________<br>
          LLVM Developers mailing list<br>
          <a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
            moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
          <a
            href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>