[llvm-bugs] [Bug 40209] New: Problems in DBG_VALUE handling in RegStackify

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40209

            Bug ID: 40209
           Summary: Problems in DBG_VALUE handling in RegStackify
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: aheejin at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 21289
  --> https://bugs.llvm.org/attachment.cgi?id=21289&action=edit
Test case with multiple defs within a BB

It looks DBG_VALUE instruction handling in RegStackify, which was added in
https://reviews.llvm.org/D49034 (https://reviews.llvm.org/rL343007) 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

```

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190103/a3c585d9/attachment.html>