[llvm-bugs] [Bug 39845] New: [DebugInfo at O2] CodeGenPrepare drops reference to local in dbg.value intrinsic

[via llvm-bugs]

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

            Bug ID: 39845
           Summary: [DebugInfo at O2] CodeGenPrepare drops reference to local
                    in dbg.value intrinsic
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: Wolfgang_Pieb at playstation.sony.com
                CC: llvm-bugs at lists.llvm.org

extern void use(int);
extern int foo(long long);

void test(int p)
{
  int i = p + 4;
  (void)foo(i);  // sign extension of i
  if (p)
    return;
  use(i);        // use of original i
}
// =====================================

Compile with -g -O2.

CodeGenPrepare seems to drop a reference to a local from a dbg.value
intrinsic:

*** IR Dump Before CodeGen Prepare ***
...
entry:
  call void @llvm.dbg.value(metadata i32 %p, metadata !12, ...
  %add = add nsw i32 %p, 4, !dbg !15
  call void @llvm.dbg.value(metadata i32 %add, metadata !13, ...

*** IR Dump After CodeGen Prepare ***
entry:
  call void @llvm.dbg.value(metadata i32 %p, metadata !12, ...
  %add = add nsw i32 %p, 4, !dbg !15
  call void @llvm.dbg.value(metadata !2, metadata !13, ...

with:
!2 = !{}
!13 = !DILocalVariable(name: "i", scope: !7, ...

So "i" does not get any location information in the .o.
If we change "foo" to take an int instead of a long long, the reference
is not dropped, and i has good location info.

On initial investigation it seems that CodeGenPrepare tries to 
optimize sign/zero extensions and in the process replaces all uses of operands
that it found worthy of extension with the extended versions.
When it finds that the optimization is not worth it (after it has already
performed it), it attempts to undo the replacement, but fails to restore
the Metadata uses.

It might be worth assessing whether this optimization is really all that
useful, or find a way to restore the Metadata uses correctly.

-- 
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/20181130/c1b08d3b/attachment.html>