https://bugs.llvm.org/show_bug.cgi?id=36410
Bug ID: 36410
Summary: Merging inlined llvm.dbg.value creates broken metadata
Product: libraries
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: uweig...@de.ibm.com
CC: apra...@apple.com, llvm-bugs@lists.llvm.org,
v...@apple.com
Created attachment 19882
--> https://bugs.llvm.org/attachment.cgi?id=19882&action=edit
Test case - run with "opt -simplifycfg"
Running the attached test case through "opt -simplifycfg" results in:
mismatched subprogram between llvm.dbg.value variable and !dbg attachment
LLVM ERROR: Broken module found, compilation aborted!
The problem seems to be that (after inlining) the test case contains two
llvm.dbg.value statements that were inlined from a subroutine:
call void @llvm.dbg.value(metadata i64 %vala, metadata !8, metadata
!DIExpression()), !dbg !12
call void @llvm.dbg.value(metadata i64 %valb, metadata !8, metadata
!DIExpression()), !dbg !13
!4 = distinct !DISubprogram(name: "callee", scope: !2, file: !2, line: 1, type:
!5, isLocal: false, isDefinition: true, scopeLine: 1, isOptimized: false, unit:
!1, variables: !7)
!10 = distinct !DISubprogram(name: "caller", scope: !2, file: !2, line: 5,
type: !5, isLocal: false, isDefinition: true, scopeLine: 5, isOptimized: false,
unit: !1, variables: !3)
!11 = distinct !DILocation(line: 6, scope: !10)
!12 = !DILocation(line: 2, scope: !4, inlinedAt: !11)
!13 = !DILocation(line: 3, scope: !4, inlinedAt: !11)
These two statements are now being merged as part of a SimplifyCFG operation.
The resulting llvm.dbg.value instruction gets a new !dbg metadata as part of an
applyMergedLocation call. This is now:
call void @llvm.dbg.value(metadata i64 %vala, metadata !7, metadata
!DIExpression()), !dbg !11
!11 = !DILocation(line: 0, scope: !4)
The numbers are off since all the metadata was renamed. But the important
change is that this is now no longer an "inline" location, but a location that
points directly to some line in "caller". But the *variable* identified by the
llvm.dbg.value of course remains a local variable of the inlined "callee"
function.
The module verifier now aborts because a llvm.dbg.value statement for a
variable in "callee" has a location in "caller".
Reading the code in applyMergedLocation / getMergedLocation and the comments in
https://reviews.llvm.org/D39628
this behavior seems to have been deliberate? But at least for llvm.dbg.value
statements this doesn't look appropriate.
I'm not sure exactly how to fix that, so any advice would be appreciated.
--
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
