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