[llvm-dev] FYI: Relocating vector of pointers

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 22 13:06:07 PST 2016

The old code path has now been completely removed.


On 01/14/2016 04:19 PM, Philip Reames wrote:
> I've also updated the docs to reflect these changes:
> http://llvm.org/docs/Statepoints.html#stack-map-format
> Philip
> On 01/14/2016 03:46 PM, Philip Reames via llvm-dev wrote:
>> TLDR. For anyone who is using the RewriteStatepointsForGC utility 
>> pass, there is a recent change you should know about which may 
>> require you to make some small changes to your stackmap parsing.
>> I have landed a small series of patches which change how we're 
>> handling vector of pointers when reporting live pointers for the GC 
>> at safepoints.  Previously, the RS4GC pass was attempting to 
>> scalarize any such vectors which were live over a safepoint so that 
>> it could insert explicit relocations for each element of the vector.  
>> In the near future, this scalarization code will be removed and we 
>> will report the vector of pointers directly in the stack map for the 
>> associated safepoints.
>> This will require each consumer to the GC stackmap recorded in 
>> LLVM_StackMap to make a small change to your parsing.  In particular, 
>> you could previously assume that all operands in the GC section were 
>> pointer sized.  With the new code, your parsing must be ready to 
>> encounter a spill slot which is a multiple of the pointer size.  The 
>> interpretation of such a slot is as a collection of pointer slots, 
>> one for each pointer-size bytes in the reported spill slot.  (i.e. a 
>> spill slot for a 4 element wide pointer vector on x86_64 will be 32 
>> bytes wide and contain 4 slots representing one pointer each.)
>> If adding the additional handling in your VM is problematic, please 
>> let me know.  Joseph Tremoulet pointed out to me that we could do the 
>> conversion before actually writing the stack map record (i.e. report 
>> 4 distinct pointer slots instead of 1 4-element vector slot) and that 
>> this might be helpful for handling first-class aggregates in the 
>> future.  At the moment, the changes to convert before writing the 
>> stack map records appear to be a bit more work than is justified, but 
>> if anyone has a reason why they need these changes, they could be done.
>> At the moment, the new functionality is hidden behind a hidden opt 
>> flag.  You can specify "-rs4gc-split-vector-values=0" to enable the 
>> new code for testing purposes.  Unless someone objects, I plan to 
>> flip the default and delete the old code within the next week or so.
>> The changes are:
>> 256352: [Statepoints] Use Indirect operands for spill slots 
>> <http://reviews.llvm.org/rL256352>
>> 257022: [Statepoints] Initial support for relocating vectors of 
>> pointers <http://reviews.llvm.org/rL257022>
>> 257244: [rs4gc] Optionally directly relocated vector of pointers 
>> <http://reviews.llvm.org/rL257244>
>> Philip
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://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/20160222/b3dbd5dc/attachment.html>

More information about the llvm-dev mailing list