<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">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">GitHub</a> <a href="https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/" target="_blank">LinkedIn</a> <a href="https://medium.com/@kavindugimhanzoysa" target="_blank">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">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">https://github.com/KavinduZoysa</a>> LinkedIn <br>
>> <<a href="https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/" rel="noreferrer" target="_blank">https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/</a>> Medium <br>
>> <<a href="https://medium.com/@kavindugimhanzoysa" rel="noreferrer" target="_blank">https://medium.com/@kavindugimhanzoysa</a>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">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">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">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">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>