[llvm-bugs] [Bug 46020] New: [DebugInfo at O1] SelectionDAG misses DebugLoc coverage on instrs that might be artificial

[via llvm-bugs]

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

            Bug ID: 46020
           Summary: [DebugInfo at O1] SelectionDAG misses DebugLoc coverage
                    on instrs that might be artificial
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: wrong-debug
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: greg.bedwell at sony.com, llvm-bugs at lists.llvm.org,
                    orlando.hyams at sony.com, paul.robinson at am.sony.com,
                    vsk at apple.com
            Blocks: 38768

This may be more of an interesting limitation than a bug, but I thought it was
worth writing up for people to see. Below, SelectionDAG creates an "artificial"
LEA to compute an address, which gets an empty DebugLoc. But it effectively
becomes a "real" instruction during register allocation, where a COPY that
_does_ have a  DebugLoc gets folded into it. The code comes from bug 46007,
copied here:

--------8<--------
void foo(char *x) {
  *x = 1;
}

int main(int argc, char **argv) {
  char c[10];
  foo(c);
  return 0;
}
-------->8--------

Which, when compiled -O1 -g with this weeks master, produces the following x86:

00:  sub    $0x19,%rsp
04:  lea    0xe(%rsp),%rdi
09:  callq  400480 <foo>

And the following line table:

Address Line Column File   ISA Discriminator Flags
------ ----- ------ ------ --- ------------- -------------
0x00       5      0      1   0             0  is_stmt
0x09       7      3      1   0             0  is_stmt prologue_end

My observation here is that if you launch this program under gdb with 'start',
it breaks into the program at the call instruction / address 0x9, missing the
opportunity to read argc in rdi before it's clobbered.

I would have expected that LEA to become part of the "call" line of the
program, as it's part of the call setup. If it had, it would be the
prologue_end instruction, and we'd be able to see argc on entry. However, what
we get immediately after isel is this:

  ADJCALLSTACKDOWN64 [...] debug-location !35; test.c:7:3
  %2:gr64 = LEA64r %stack.0.c, 1, $noreg, 0, $noreg
  $rdi = COPY %2:gr64, debug-location !35; test.c:7:3
  CALL64pcrel32 @foo, [...]

During SelectionDAG, the argument setup has the right line number, and it comes
out attached to the COPY:

  t12: ch,glue = CopyToReg [ORD=5] [ID=12]
    # D:0 t10, Register:i64 $rdi [ID=4]
    # D:0, FrameIndex:i64<0> [ID=1] # D:0, test.c:7:3

The FrameIndex node is converted into an LEA, and because it looks like it's
artificial, it isn't given a DebugLoc. However, that's not what the code ends
up meaning: the copy effectively becomes a hint to the register allocator, and
the LEA is what really sets up the call.

I don't have any intuition as to whether this is fixable, or whether this
happens in more circumstances, but (to me) it's definitely sub-optimal.


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=38768
[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/20200521/76d9d83e/attachment.html>