Philip Reames via llvm-dev
2021-May-07 15:33 UTC
[llvm-dev] Reason to use different address space for statepoints
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
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>