Kavindu Gimhan Zoysa via llvm-dev
2021-May-07 16:23 UTC
[llvm-dev] Reason to use different address space for statepoints
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> 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> LinkedIn > >> <https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/> Medium > >> <https://medium.com/@kavindugimhanzoysa> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > 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/506ae415/attachment.html>
Philip Reames via llvm-dev
2021-May-07 16:24 UTC
[llvm-dev] Reason to use different address space for statepoints
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>