llvm dev - Jan 2016 - FYI: Relocating vector of pointers

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160114/04687c98/attachment-0001.html>

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/20160114/2dc56286/attachment.html>

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>