<html>
<head>
<base href="https://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 --- - WinEH funclet entries/exits "kill" volatile registers"
href="https://llvm.org/bugs/show_bug.cgi?id=25398">25398</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>WinEH funclet entries/exits "kill" volatile registers
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</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>Register Allocator
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>JCTremoulet@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=15215" name="attach_15215" title="File that miscompiles (64-bit, with -code-model=large)">attachment 15215</a> <a href="attachment.cgi?id=15215&action=edit" title="File that miscompiles (64-bit, with -code-model=large)">[details]</a></span>
File that miscompiles (64-bit, with -code-model=large)
The rules around WinEH funclets need to be correctly modeled in the register
allocator:
- On entry to a funclet, all registers may be trashed
- On exit from a funclet, volatile registers may be trashed, and nonvolatile
registers will be restored *to the value they had just prior to the exception*
32-bit WinEH has a workaround that just models calls which may transition to
funclets as killing all registers, which is conservatively correct.
64-bit WinEH does not (yet?) have such a workaround, which could lead to
miscompiles, as in the attached bad_regalloc.ll (which needs -code-model=large
to expose the bug, and tries to hold the call target in rsi across a funclet
entry where it may be trashed).
While the workaround is conservatively correct, it imposes a rather severe
penalty on the non-exceptional path around exceptional constructs, so the real
work here is to find a correct, less conservative solution.
A good first step would be modeling the kills as happening on the exceptional
path out of the invoke but not the normal path out of it. This requires
modeling them as occurring on the unsplittable edge or, equivalently, modeling
them with some operator at the start of the funclet entry block *which is glued
to the top of the block* -- the RA needs to know that it cannot insert spills
after the edge and before the kill, which IIUC is a novel constraint for LLVM's
RA.
A good second step would be to recognize when the only appearance of some
nonvolatile register in a function is its apparent kill at one of these funclet
boundaries, and suppress the save/restore that would otherwise be inserted to
preserve its value for the current function's caller, since the runtime will
already restore its value on exit from the funclet.
A third step would be to take advantage of the runtime's restoring of these
values on funclet exit, enregistering candidates across entire catch handlers
when those candidates are not modified within the handler.</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>