[llvm-bugs] [Bug 25512] New: Optimization corrupts debug info

[via llvm-bugs]

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

            Bug ID: 25512
           Summary: Optimization corrupts debug info
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: danielcdh at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Source: a.cc
  1 int *A;
  2 void bar(int i);
  3 
  4 void foo(int i) {
  5   if (i > 100) {
  6     bar(A[20]);
  7   } else {
  8     bar(A[15]);
  9   }
 10 }

#clang -g a.cc -c -O2
#objdump -d a.o
0000000000000000 <_Z3fooi>:
   0:    48 8b 05 00 00 00 00     mov    0x0(%rip),%rax        # 7
<_Z3fooi+0x7>
   7:    83 ff 65                 cmp    $0x65,%edi
   a:    7c 08                    jl     14 <_Z3fooi+0x14>
   c:    8b 78 50                 mov    0x50(%rax),%edi
   f:    e9 00 00 00 00           jmpq   14 <_Z3fooi+0x14>
  14:    8b 78 3c                 mov    0x3c(%rax),%edi
  17:    e9 00 00 00 00           jmpq   1c <_Z3fooi+0x1c>
#addr2line -e a.o -i 0x0
/ssd/llvm_commit/build.afdo/a.cc:6

The problem is, the first mov instruction is attributed to the source that's in
the taken branch. From debugger's point of few, when you enter this function,
gdb will start with line #6, even though the logic does not get into #6 at all.

This makes things worse when using debug info to represent profile. In this
case, #6 will have the same count as the branch entry. As a result, even if the
branch is never taken, the profile will still consider the branch as at least
50% taken.

There are many optimizations that would have this effect. Usually, compiler
developers does not care too much about debugging of optimized code. But if we
can address most issues like this where optimizations would skew the debug
info, not only can we have better debugging experience of optimized code, we
also get better performance when using sampling based profile to guide
optimizations.

-- 
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/20151112/6c9954dc/attachment.html>