<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
The old code path has now been completely removed.<br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 01/14/2016 04:19 PM, Philip Reames
wrote:<br>
</div>
<blockquote cite="mid:56983AF5.9050608@philipreames.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
I've also updated the docs to reflect these changes:<br>
<a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" 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>
</blockquote>
<br>
</body>
</html>