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: unassignedb...@nondot.org
Reporter: daniel...@gmail.com
CC: llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
