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

[Philip Reames via llvm-dev]

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