<html>
<head>
<base href="https://bugs.llvm.org/">
</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 - Problems in DBG_VALUE handling in RegStackify"
href="https://bugs.llvm.org/show_bug.cgi?id=40209">40209</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Problems in DBG_VALUE handling in RegStackify
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</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>Backend: WebAssembly
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>aheejin@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=21289" name="attach_21289" title="Test case with multiple defs within a BB">attachment 21289</a> <a href="attachment.cgi?id=21289&action=edit" title="Test case with multiple defs within a BB">[details]</a></span>
Test case with multiple defs within a BB
It looks DBG_VALUE instruction handling in RegStackify, which was added in
<a href="https://reviews.llvm.org/D49034">https://reviews.llvm.org/D49034</a> (<a href="https://reviews.llvm.org/rL343007">https://reviews.llvm.org/rL343007</a>) has several
problems.
1. `MoveDebugValues` and `UpdateDebugValuesReg` do not seem to consider the
case where there are multiple defs to a single register within a BB. Currently
they treat all `DBG_VALUE` instruction to a register as a group and move /
update them together whenever any one of the definitions of the register in a
BB is stackified. A sample test case with multiple defs within a BB that fails
is attached.
2. In `UpdateDebugValuesReg` function,
```
static void UpdateDebugValuesReg(unsigned Reg, unsigned NewReg,
MachineBasicBlock &MBB,
MachineRegisterInfo &MRI) {
for (auto &Op : MRI.reg_operands(Reg)) {
MachineInstr *MI = Op.getParent();
assert(MI != nullptr);
if (MI->isDebugValue() && MI->getParent() == &MBB)
Op.setReg(NewReg);
}
}
```
Here `Op.setReg(NewReg)` modifies the iterator `MRI.reg_operands(Reg)` while
traversing it. So this ends up hitting only the first element and bailing out.
This function has problems even without this bug because of the 1 above though.
3. `CloneDebugValues` function does not consider a case that an instruction to
be rematerialized is in another BB. Even though RegStackify mostly work within
a BB, when a def is trivially rematerializable, i.e., `const_i32` instruction,
that instruction can be another BB and can be copied to this BB. But
`CloneDebugValues` limit the search within this BB by `MI->getParent() == &MBB`
clause, so in that case the debug value for the rematerialized instruction will
not be cloned. A test case can be made trivially, so I'm not gonna attach an
mir file for that, but it should look like this:
```
bb1:
%3 = const_i32 3 ; This is trivially rematerializable
...
bb2:
...
use %3
```</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>