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

[Kavindu Gimhan Zoysa via llvm-dev]

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>