You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the code below, CodeGenPrepare duplicates the GEP calculating the %bees pointer and sinks the copy into the "next:" block. This is fine, and is designed to allow the address calculations to be folded into a machine addressing mode. The dbg.value for %bees is left in a BB where there are no other uses of %bees, and normally CodeGenPrepare's placeDbgValues would move the dbg.value into the earlier BB to avoid limitations in SelectionDAG.
However, as explored in bug 38754, this isn't a good solution, and causes the appearance of variables to the developer to be re-ordered in the debugger. When placeDbgValues is turned off, the dbg.value stays in the later BB. Then in SelectionDAG, because %bees isn't used outside of the first BB, no VReg is allocated to it, and there's no way to turn the dbg.value into a legal DBG_VALUE. The dbg.value is subsequently dropped.
I've been using the latest trunk (r348754) and have been running "llc -stop-after=codegenprepare". The fix seems obvious (update debug users in CodeGenPrepare::optimizeMemoryInst) however it's not clear whether a fix can be tested if it depends on placeDbgValues being disabled.
Extended Description
In the code below, CodeGenPrepare duplicates the GEP calculating the %bees pointer and sinks the copy into the "next:" block. This is fine, and is designed to allow the address calculations to be folded into a machine addressing mode. The dbg.value for %bees is left in a BB where there are no other uses of %bees, and normally CodeGenPrepare's placeDbgValues would move the dbg.value into the earlier BB to avoid limitations in SelectionDAG.
However, as explored in bug 38754, this isn't a good solution, and causes the appearance of variables to the developer to be re-ordered in the debugger. When placeDbgValues is turned off, the dbg.value stays in the later BB. Then in SelectionDAG, because %bees isn't used outside of the first BB, no VReg is allocated to it, and there's no way to turn the dbg.value into a legal DBG_VALUE. The dbg.value is subsequently dropped.
I've been using the latest trunk (r348754) and have been running "llc -stop-after=codegenprepare". The fix seems obvious (update debug users in CodeGenPrepare::optimizeMemoryInst) however it's not clear whether a fix can be tested if it depends on placeDbgValues being disabled.
-------->8--------
declare void @llvm.dbg.value(metadata, metadata, metadata)
define i32 @lala(i32 %ptr, i1 %arg) {
%bees = getelementptr i32, i32 %ptr, i32 4
%loaded = load i32, i32 *%bees
br i1 %arg, label %next, label %face
next:
call void @llvm.dbg.value(metadata i32 *%bees, metadata !1, metadata !DIExpression()), !dbg !6
store i32 1, i32 *%bees
ret i32 1
face:
ret i32 0
}
!llvm.module.flags = !{#4}
!llvm.dbg.cu = !{#2}
!1 = !DILocalVariable(name: "bees", scope: !5, type: null)
!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer: "beards", isOptimized: true, runtimeVersion: 4, emissionKind: FullDebug)
!3 = !DIFile(filename: "bees.cpp", directory: "")
!4 = !{i32 2, !"Debug Info Version", i32 3}
!5 = distinct !DISubprogram(name: "nope", scope: !2, file: !3, line: 1, unit: !2)
!6 = !DILocation(line: 0, scope: !5)
--------8<--------
The text was updated successfully, but these errors were encountered: