<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I've also updated the docs to reflect these changes:<br>
<a class="moz-txt-link-freetext" href="http://llvm.org/docs/Statepoints.html#stack-map-format">http://llvm.org/docs/Statepoints.html#stack-map-format</a><br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 01/14/2016 03:46 PM, Philip Reames
via llvm-dev wrote:<br>
</div>
<blockquote cite="mid:56983352.8020306@philipreames.com" type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
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.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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. <br>
<br>
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.<br>
<br>
The changes are:<br>
<a moz-do-not-send="true" href="http://reviews.llvm.org/rL256352"
class="phui-handle">256352: [Statepoints] Use Indirect operands
for spill slots</a> <br>
<a moz-do-not-send="true" href="http://reviews.llvm.org/rL257022"
class="phui-handle">257022: [Statepoints] Initial support for
relocating vectors of pointers</a><br>
<a moz-do-not-send="true" href="http://reviews.llvm.org/rL257244"
class="phui-handle">257244: [rs4gc] Optionally directly
relocated vector of pointers</a> <br>
<br>
Philip<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>