[llvm-bugs] [Bug 39755] New: [DebugInfo at O2][Dexter] dbg.value's of isel vreg's can be accidentally dropped

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Nov 22 08:34:00 PST 2018


            Bug ID: 39755
           Summary: [DebugInfo at O2][Dexter] dbg.value's of isel vreg's can
                    be accidentally dropped
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Keywords: wrong-debug
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: chackz0x12 at gmail.com, greg.bedwell at sony.com,
                    international.phantom at gmail.com,
                    llvm-bugs at lists.llvm.org, paul.robinson at am.sony.com
            Blocks: 38754, 38768

This bug is spun out of bug 38754 to represent a regression I saw there; using
llvm/clang r346686 with options "-O2 -g -fno-inline", and with CodeGenPrepare's
placeDbgValues function disabled, the "blah" variable in the code below does
not get a location. (It does if placeDbgValues is enabled).

struct faces {
  unsigned bar : 15;
  unsigned baz : 15;
  unsigned qux : 1;
  unsigned wat;

void forks(faces *foo, bool cond, int someval) {
  foo->wat = foo->bar;
  if (someval == 4) {
    unsigned blah = foo->bar;
    foo->baz = 3;
    if (cond)
      blah |= 4;
      blah |= 8;
    foo->bar = blah;

  volatile int foo = 4;
  bool cond = foo == 4;
  faces spoon;
  spoon.bar = 0;
  spoon.baz = 0;
  forks(&spoon, cond, foo);
  return spoon.bar;

The IR for the start of the outer conditional block in the 'forks' function,
where !24 is the DIVariable for "blah":

  if.then:                                          ; preds = %entry
    %1 = bitcast %struct.faces* %foo to i32*
    call void @llvm.dbg.value(metadata i32 %bf.clear, metadata !24, [...])
    %bf.clear4 = and i32 %bf.load, -1073741824
    call void @llvm.dbg.value(metadata i32 undef, metadata !24, [...])
    %blah.0 = select i1 %cond, i32 98308, i32 98312

Some facts:
 * The inner condition has been optimised into a single select instruction
 * The stores to foo->baz and foo->bar gets merged into a single store
 * The read of foo->bar at the start of the function makes the field live
   in the %bf.clear SSA register, the whole memory word lives in %bf.load
 * The middle line (the "and" instruction) survives into the object file

With the IR above, I would expect that "blah" would have a location on the
"and" instruction, and to then lose it afterwards. The dbg.value(undef) comes
from the merged stores getting instcombined with the logic insns, leaving no
single value for "blah".

Unfortunately, the first dbg.value dangles because %bf.clear isn't read until a
few insns further down the IR BB, and the dbg.value(undef) then causes the
first one to get dropped. That feature [0] is to avoid emitting spurious
DBG_VALUEs after a new valuation is available; in this circumstance we end up
dropping a legitimate dbg.value because we didn't know it was _going_ to be
legitimate yet.

IMHO, in the theme of this WIP [1] patch, we need to distinguish what's a
read/write of a VReg from general SDNodes. The value being referred to (in a
VReg) is already available and the DBG_VALUE could be emitted without
generating spurious code, we just don't recognise it.

There's also the matter that the value of "blah" could probably be recovered
from the instcombined Value, but is instead marked as undef, however that's
probably a different ticket.

[1] https://reviews.llvm.org/D54715

Referenced Bugs:

[Bug 38754] [DebugInfo at O2][Dexter] Illegal value appears in variable when
conditional blocks folded
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
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/20181122/bc31aaec/attachment.html>

More information about the llvm-bugs mailing list