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

[Kavindu Gimhan Zoysa via llvm-dev]

Hi Philip,

Sounds good, Shall we try a google hangouts call or zoom call?

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:55, Philip Reames <listmail at philipreames.com>
wrote:

> 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> 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/8088e20d/attachment.html>