<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - llvm.lifetime.start/end conflict with use of llvm.gcroot"
href="http://llvm.org/bugs/show_bug.cgi?id=16778">16778</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>llvm.lifetime.start/end conflict with use of llvm.gcroot
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>3.2
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>other
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>don.apoch@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=10975" name="attach_10975" title="Example IR code which causes the issue">attachment 10975</a> <a href="attachment.cgi?id=10975&action=edit" title="Example IR code which causes the issue">[details]</a></span>
Example IR code which causes the issue
There appears to be a fundamental conflict of interest between
llvm.lifetime.start/end intrinsics and the use of the llvm.gcroot intrinsic.
Due to the merging of stack slots, it is possible for GC roots to contain
unexpected values if the GC is triggered at certain points in the lifetime of
the stack slot(s) in question.
This is mostly exacerbated by the function inlining pass, which introduces
lifetime intrinsics to the IR.
Consider the following scenario:
- Function A uses one stack slot which is a GC root
- Function B uses three stack slots, two of which are GC roots and one is not
- Function B calls function A
- The call to A becomes inlined due to optimization passes
- GC safepoints (and therefore collector invocations) can occur before and/or
after the call to A
In this case the optimizer introduces lifetime.start and .end calls surrounding
the stack slot used by function A. Given the right circumstances this can merge
the stack slot used by A into the non-gcroot slot used by function B. (Other
scenarios I've observed include merging the slot into a different gcroot stack
slot, which then carries the wrong metadata.)
If the GC is invoked at the right time during this sequence, it will attempt to
traverse a root which does not in fact contain a valid pointer. Again the other
possible scenario is that the pointer *is* valid but is associated with the
wrong metadata.
Since gcroot carries no lifetime semantics, it appears to be fundamentally
impossible to mix the use of gcroot with lifetime.start/end. I am currently
working around this issue by using a GCStrategy with a custom lowering pass
that simply eliminates lifetime intrinsic calls, but obviously this incurs some
expense in terms of stack space.
I'm attaching a case that reproduces this behavior; the various calls can
largely be ignored except for the calls that trigger garbage collection passes.
I apologize in advance for the large sample case, but it's proven extremely
difficult to get this to reliably repro in simpler scenarios.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>