[llvm-bugs] [Bug 31878] New: CodeGenPrepare::placeDbgValues moves llvm.dbg.value without proper analysis
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Feb 6 07:40:53 PST 2017
https://llvm.org/bugs/show_bug.cgi?id=31878
Bug ID: 31878
Summary: CodeGenPrepare::placeDbgValues moves llvm.dbg.value
without proper analysis
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedbugs at nondot.org
Reporter: mattias.v.eriksson at ericsson.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
I think CodeGenPrepare::placeDbgValues moves llvm.dbg.value too much
in this example:
Input to CodeGenPrepare. The interesting part is the last call to
llvm.dbg.value
*** IR Dump Before CodeGen Prepare ***
; Function Attrs: noinline nounwind
define void @move(i16 %from.9.par, i16 %to.10.par, i16 %aux.11.par, i16
%n.12.par, [7 x i16]* nocapture %poles.13.par, i16* nocapture %height.14.par)
local_unnamed_addr #1 !dbg !6 {
tail call void @llvm.dbg.value(metadata i16 %n.12.par, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp49 = getelementptr i16, i16* %height.14.par, i16 %to.10.par, !dbg !18
%_tmp55 = mul i16 %to.10.par, 7, !dbg !18
%_tmp57 = getelementptr [7 x i16], [7 x i16]* %poles.13.par, i16 0, i16
%_tmp55, !dbg !18
br label %bb0, !dbg !19
bb0: ; preds = %bb2, %0
%n.12.0 = phi i16 [ %n.12.par, %0 ], [ %_tmp64, %bb2 ]
%aux.11.0 = phi i16 [ %aux.11.par, %0 ], [ %from.9.0, %bb2 ]
%from.9.0 = phi i16 [ %from.9.par, %0 ], [ %aux.11.0, %bb2 ]
tail call void @llvm.dbg.value(metadata i16 %n.12.0, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp59 = icmp sgt i16 %n.12.0, 1, !dbg !20
%_tmp64 = add nsw i16 %n.12.0, -1
br i1 %_tmp59, label %bb1, label %bb2, !dbg !20
bb1: ; preds = %bb0
tail call void @move(i16 %from.9.0, i16 %aux.11.0, i16 %to.10.par, i16
%_tmp64, [7 x i16]* %poles.13.par, i16* %height.14.par), !dbg !21
br label %bb2, !dbg !21
bb2: ; preds = %bb1, %bb0
%_tmp68 = load i16, i16* %_tmp49, align 1, !dbg !23
%_tmp70 = add i16 %_tmp68, 1, !dbg !24
store i16 %_tmp70, i16* %_tmp49, align 1, !dbg !24
%_tmp75 = getelementptr i16, i16* %height.14.par, i16 %from.9.0, !dbg !24
%_tmp77 = load i16, i16* %_tmp75, align 1, !dbg !24
%_tmp78 = add i16 %_tmp77, -1, !dbg !24
store i16 %_tmp78, i16* %_tmp75, align 1, !dbg !24
%_tmp83 = mul i16 %from.9.0, 7, !dbg !24
%_tmp85 = getelementptr [7 x i16], [7 x i16]* %poles.13.par, i16 0, i16
%_tmp83, !dbg !24
%_tmp89 = getelementptr i16, i16* %_tmp85, i16 %_tmp78, !dbg !24
%_tmp90 = load i16, i16* %_tmp89, align 1, !dbg !24
%_tmp94 = getelementptr i16, i16* %_tmp57, i16 %_tmp68, !dbg !24
store i16 %_tmp90, i16* %_tmp94, align 1, !dbg !24
%_tmp9712 = load i16, i16* %_tmp75, align 1, !dbg !25
%_tmp99 = getelementptr i16, i16* %_tmp85, i16 %_tmp9712, !dbg !25
store i16 0, i16* %_tmp99, align 1, !dbg !25
tail call void @show([7 x i16]* %poles.13.par, i16* undef), !dbg !26
;;;;;; Here "n" should get the updated value (n = n - 1).
tail call void @llvm.dbg.value(metadata i16 %_tmp64, i64 0, metadata !15,
metadata !16), !dbg !17
%1 = add i16 %_tmp64, 1, !dbg !20
%bb0.termcond = icmp sgt i16 %1, 1, !dbg !20
br i1 %bb0.termcond, label %bb0, label %bb4, !dbg !27
bb4: ; preds = %bb2
ret void, !dbg !28
}
!15 = !DILocalVariable(name: "n", arg: 4, scope: !6, line: 47, type: !9)
And here's the output, note how the last llvm.dbg.value has been moved
to %bb0.
*** IR Dump After CodeGen Prepare ***
; Function Attrs: noinline nounwind
define void @move(i16 %from.9.par, i16 %to.10.par, i16 %aux.11.par, i16
%n.12.par, [7 x i16]* nocapture %poles.13.par, i16* nocapture %height.14.par)
local_unnamed_addr #1 !dbg !6 {
tail call void @llvm.dbg.value(metadata i16 %n.12.par, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp49 = getelementptr i16, i16* %height.14.par, i16 %to.10.par, !dbg !18
%_tmp55 = mul i16 %to.10.par, 7, !dbg !18
%_tmp57 = getelementptr [7 x i16], [7 x i16]* %poles.13.par, i16 0, i16
%_tmp55, !dbg !18
br label %bb0, !dbg !19
bb0: ; preds = %bb2, %0
%n.12.0 = phi i16 [ %n.12.par, %0 ], [ %_tmp64, %bb2 ]
%aux.11.0 = phi i16 [ %aux.11.par, %0 ], [ %from.9.0, %bb2 ]
%from.9.0 = phi i16 [ %from.9.par, %0 ], [ %aux.11.0, %bb2 ]
tail call void @llvm.dbg.value(metadata i16 %n.12.0, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp59 = icmp sgt i16 %n.12.0, 1, !dbg !20
%_tmp64 = add nsw i16 %n.12.0, -1
;;;;; Now "n" is updated with its new value already in this block.
tail call void @llvm.dbg.value(metadata i16 %_tmp64, i64 0, metadata !15,
metadata !16), !dbg !17
br i1 %_tmp59, label %bb1, label %bb2, !dbg !20
bb1: ; preds = %bb0
tail call void @move(i16 %from.9.0, i16 %aux.11.0, i16 %to.10.par, i16
%_tmp64, [7 x i16]* %poles.13.par, i16* %height.14.par), !dbg !21
br label %bb2, !dbg !21
bb2: ; preds = %bb1, %bb0
%_tmp68 = load i16, i16* %_tmp49, align 1, !dbg !23
%_tmp70 = add i16 %_tmp68, 1, !dbg !24
store i16 %_tmp70, i16* %_tmp49, align 1, !dbg !24
%_tmp75 = getelementptr i16, i16* %height.14.par, i16 %from.9.0, !dbg !24
%_tmp77 = load i16, i16* %_tmp75, align 1, !dbg !24
%_tmp78 = add i16 %_tmp77, -1, !dbg !24
store i16 %_tmp78, i16* %_tmp75, align 1, !dbg !24
%_tmp83 = mul i16 %from.9.0, 7, !dbg !24
%_tmp85 = getelementptr [7 x i16], [7 x i16]* %poles.13.par, i16 0, i16
%_tmp83, !dbg !24
%_tmp89 = getelementptr i16, i16* %_tmp85, i16 %_tmp78, !dbg !24
%_tmp90 = load i16, i16* %_tmp89, align 1, !dbg !24
%_tmp94 = getelementptr i16, i16* %_tmp57, i16 %_tmp68, !dbg !24
store i16 %_tmp90, i16* %_tmp94, align 1, !dbg !24
%_tmp9712 = load i16, i16* %_tmp75, align 1, !dbg !25
%_tmp99 = getelementptr i16, i16* %_tmp85, i16 %_tmp9712, !dbg !25
store i16 0, i16* %_tmp99, align 1, !dbg !25
tail call void @show([7 x i16]* %poles.13.par, i16* undef), !dbg !26
%1 = add i16 %_tmp64, 1, !dbg !20
%bb0.termcond = icmp sgt i16 %1, 1, !dbg !20
br i1 %bb0.termcond, label %bb0, label %bb4, !dbg !27
bb4: ; preds = %bb2
ret void, !dbg !28
}
Running the resulting code in a debugger shows an incorrect value for
the variable n. In this case it would have been better if this call to
llvm.dbg.value had been dropped instead of moved.
I discovered this in a testcase in our out-of-tree target. If you
agree that this looks like a bug I can try to make a reproducer for an
in-tree target.
--
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/20170206/171c867a/attachment.html>
More information about the llvm-bugs
mailing list