<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Incorrect debug values for variables due to phi-related DBG_VALUEs moved in ISel"
href="https://bugs.llvm.org/show_bug.cgi?id=34477">34477</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Incorrect debug values for variables due to phi-related DBG_VALUEs moved in ISel
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>david.stenberg@ericsson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=19103" name="attach_19103" title="Generated using `clang -O1 -g2 foo.c -S -emit-llvm -o foo.ll'">attachment 19103</a> <a href="attachment.cgi?id=19103&action=edit" title="Generated using `clang -O1 -g2 foo.c -S -emit-llvm -o foo.ll'">[details]</a></span>
Generated using `clang -O1 -g2 foo.c -S -emit-llvm -o foo.ll'
When compiling the following file, foo.c:
int end = 10;
int main() {
int x = 9;
int y = 13;
for (int u = 0; u < end; ++u) {
x += y;
y *= 3;
}
return x;
}
using clang and llc from trunk (r312489 and r312484) with the following
commands:
clang --target=x86_64-unknown-linux -O1 -g2 foo.c -S -emit-llvm -o foo.ll
(output attached as foo.ll)
llc foo.ll -o foo.s
the resulting binary will contain incorrect debug locations for the variables
`x' and `u'. For example, the value of `x' will be printed as 9 in gdb when
standing on the first instruction in the loop body, for all iterations of the
loop. The seems to be caused by the DBG_VALUE that says that `x' is stored in
a register being placed too late in the loop body:
# BB#0: # %entry
#DEBUG_VALUE: main:x <- 9
[...]
.LBB0_4: # %for.body
# =>This Inner Loop Header: Depth=1
.Ltmp1:
#DEBUG_VALUE: main:y <- %ECX
.loc 1 7 7 is_stmt 1 # foo.c:7:7
addl %ecx, %eax
.Ltmp2:
#DEBUG_VALUE: main:x <- %EAX
.loc 1 8 7 # foo.c:8:7
leal (%rcx,%rcx,2), %ecx
.Ltmp3:
.loc 1 6 28 # foo.c:6:28
addl $1, %edx
.Ltmp4:
#DEBUG_VALUE: u <- %EDX
.loc 1 6 21 is_stmt 0 # foo.c:6:21
cmpl %esi, %edx
.Ltmp5:
.loc 1 6 3 # foo.c:6:3
jl .LBB0_4
The same issue exists, and is worse, for `u', as the debug value corresponding
to the phi node is moved to the end of the loop body.
Before instruction selection:
for.body: ; preds = %for.body,
%for.body.lr.ph
%u.010 = phi i32 [ 0, %for.body.lr.ph ], [ %inc, %for.body ]
%y.09 = phi i32 [ 13, %for.body.lr.ph ], [ %mul, %for.body ]
%x.08 = phi i32 [ 9, %for.body.lr.ph ], [ %add, %for.body ]
~~~~> tail call void @llvm.dbg.value(metadata i32 %u.010, metadata !17,
metadata !DIExpression()), !dbg !21
tail call void @llvm.dbg.value(metadata i32 %y.09, metadata !16, metadata
!DIExpression()), !dbg !20
----> tail call void @llvm.dbg.value(metadata i32 %x.08, metadata !15, metadata
!DIExpression()), !dbg !19
%add = add nsw i32 %y.09, %x.08, !dbg !31
tail call void @llvm.dbg.value(metadata i32 %add, metadata !15, metadata
!DIExpression()), !dbg !19
tail call void @llvm.dbg.value(metadata i32 %add, metadata !15, metadata
!DIExpression()), !dbg !19
%mul = mul nsw i32 %y.09, 3, !dbg !33
tail call void @llvm.dbg.value(metadata i32 %mul, metadata !16, metadata
!DIExpression()), !dbg !20
tail call void @llvm.dbg.value(metadata i32 %mul, metadata !16, metadata
!DIExpression()), !dbg !20
%inc = add nuw nsw i32 %u.010, 1, !dbg !34
tail call void @llvm.dbg.value(metadata i32 %inc, metadata !17, metadata
!DIExpression()), !dbg !21
tail call void @llvm.dbg.value(metadata i32 %inc, metadata !17, metadata
!DIExpression()), !dbg !21
%cmp = icmp slt i32 %inc, %1, !dbg !28
br i1 %cmp, label %for.body, label %for.cond.cleanup, !dbg !29,
!llvm.loop !35
and after:
# *** IR Dump After X86 DAG->DAG Instruction Selection ***:
# Machine code for function main: IsSSA, TracksLiveness
[...]
BB#3: derived from LLVM BB %for.body
Predecessors according to CFG: BB#1 BB#3
%vreg2<def> = PHI %vreg9, <BB#1>, %vreg7, <BB#3>;
GR32:%vreg2,%vreg9,%vreg7
%vreg3<def> = PHI %vreg10, <BB#1>, %vreg6, <BB#3>;
GR32:%vreg3,%vreg10,%vreg6
%vreg4<def> = PHI %vreg11, <BB#1>, %vreg5, <BB#3>;
GR32:%vreg4,%vreg11,%vreg5
DBG_VALUE %vreg3, %noreg, !"y", <!DIExpression()>; GR32:%vreg3 line
no:5
%vreg5<def,tied1> = ADD32rr %vreg3<tied0>, %vreg4,
%EFLAGS<imp-def,dead>; GR32:%vreg5,%vreg3,%vreg4 dbg:foo.c:7:7
----> DBG_VALUE %vreg4, %noreg, !"x", <!DIExpression()>; GR32:%vreg4 line
no:4
DBG_VALUE %vreg5, %noreg, !"x", <!DIExpression()>; GR32:%vreg5 line
no:4
DBG_VALUE %vreg5, %noreg, !"x", <!DIExpression()>; GR32:%vreg5 line
no:4
%vreg12<def> = SUBREG_TO_REG 0, %vreg3, sub_32bit; GR64_NOSP:%vreg12
GR32:%vreg3 dbg:foo.c:8:7
%vreg6<def> = LEA64_32r %vreg12, 2, %vreg12, 0, %noreg; GR32:%vreg6
GR64_NOSP:%vreg12 dbg:foo.c:8:7
DBG_VALUE %vreg6, %noreg, !"y", <!DIExpression()>; GR32:%vreg6 line
no:5
DBG_VALUE %vreg6, %noreg, !"y", <!DIExpression()>; GR32:%vreg6 line
no:5
%vreg7<def,tied1> = ADD32ri8 %vreg2<tied0>, 1, %EFLAGS<imp-def,dead>;
GR32:%vreg7,%vreg2 dbg:foo.c:6:28
DBG_VALUE %vreg7, %noreg, !"u", <!DIExpression()>; GR32:%vreg7 line
no:6
DBG_VALUE %vreg7, %noreg, !"u", <!DIExpression()>; GR32:%vreg7 line
no:6
%vreg13<def,tied1> = SUB32rr %vreg7<tied0>, %vreg0, %EFLAGS<imp-def>;
GR32:%vreg13,%vreg7,%vreg0 dbg:foo.c:6:21
~~~~> DBG_VALUE %vreg2, %noreg, !"u", <!DIExpression()>; GR32:%vreg2 line
no:6
JL_1 <BB#3>, %EFLAGS<imp-use>; dbg:foo.c:6:3
JMP_1 <BB#2>; dbg:foo.c:6:3
Successors according to CFG: BB#3(0x7c000000 / 0x80000000 = 96.88%)
BB#2(0x04000000 / 0x80000000 = 3.12%)
This issue is not specific to x86, and is for example also seen when targeting
ARM.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>