[llvm-dev] Reason to use different address space for statepoints

[Philip Reames via llvm-dev]

Kavindu,

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.

Philip

On 5/7/21 9:23 AM, Kavindu Gimhan Zoysa wrote:
> Hi David and Philip,
>
> Thank you for your responses. The reason to ask that question is that, 
> in this statepoints document 
> <https://releases.llvm.org/11.0.0/docs/Statepoints.html>, examples are 
> used address space 1.
>
> I would be grateful if you can check this mail thread "*Generate 
> statepoints for given code" *which was sent by me*.*
>
> Thank you,
> Kavindu
>
> Kavindu Gimhan Zoysa,
> BSc(Hons) | ENTC | UoM,
> SSE | WSO2
>
> GitHub <https://github.com/KavinduZoysa> LinkedIn 
> <https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/> Medium 
> <https://medium.com/@kavindugimhanzoysa>
>
>
> On Fri, 7 May 2021 at 21:03, Philip Reames via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Point of order, most of this work was done to support a Java
>     frontend.
>     CLR came later.  :)
>
>     David, your point isn't wrong, but it does miss one of the major use
>     cases.  We support both an abstract machine model and a physical
>     machine
>     model.  In the abstract machine model, objects aren't deallocated.
>     RS4GC is the lowering pass which converts from abstract to physical
>     (e.g. exposes the existence of deallocation).  In the abstract
>     model, we
>     need pointers to be "non-integral" to restrict transformations which
>     would break the reference to object abstraction.
>
>     Kavindu, if you're lowering directly to physical (e.g. generating
>     statepoints in your frontend), you shouldn't care about non-integral
>     pointers.
>
>     Philip
>
>     On 5/7/21 8:21 AM, David Chisnall via llvm-dev wrote:
>     > Hi,
>     >
>     > I'm not sure that this is a requirement.  The CLR implementation
>     that
>     > drove a lot of this work wanted to be able to track both
>     native-code
>     > pointers that were not GC'd and pointers to the GC'd heap and so
>     used
>     > AS 1 for GC'd pointers.  If you don't have this distinction then
>     you
>     > may be able to avoid it.  Note that the data layout makes a
>     > distinction at the address-space level between pointers that can be
>     > treated as integers and ones that can't. Pointers to memory with
>     > accurate GC shouldn't be treated as integers (where they may go
>     > out-of-bounds in an intermediate state and be lost to the GC).
>     >
>     > David
>     >
>     > On 07/05/2021 15:28, Kavindu Gimhan Zoysa via llvm-dev wrote:
>     >> Hi all,
>     >>
>     >> When we generate an LLVM IR introducing statepoints, do we
>     >> essentially need to use a different address space other than the
>     >> default address space? If so can you explain the reason for that?
>     >>
>     >> Thank you in advance,
>     >> Kavindu
>     >>
>     >> Kavindu Gimhan Zoysa,
>     >> BSc(Hons) | ENTC | UoM,
>     >> SSE | WSO2
>     >>
>     >> GitHub <https://github.com/KavinduZoysa
>     <https://github.com/KavinduZoysa>> LinkedIn
>     >> <https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/
>     <https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/>> Medium
>     >> <https://medium.com/@kavindugimhanzoysa
>     <https://medium.com/@kavindugimhanzoysa>>
>     >>
>     >> _______________________________________________
>     >> LLVM Developers mailing list
>     >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>     >>
>     > _______________________________________________
>     > LLVM Developers mailing list
>     > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210507/08a59389/attachment.html>