[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.
Philip
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