Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DebugInfo@O2] CodeGenPrepare address-mode sinking limits dbg.value validity #39287

Closed
jmorse opened this issue Dec 10, 2018 · 3 comments
Closed
Assignees
Labels
bugzilla Issues migrated from bugzilla wrong-debug

Comments

@jmorse
Copy link
Member

jmorse commented Dec 10, 2018

Bugzilla Link 39940
Resolution FIXED
Resolved on Dec 11, 2019 03:05
Version trunk
OS Linux
Blocks #38116 #38102
CC @dwblaikie,@gregbedwell,@CarlosAlbertoEnciso,@pogo59
Fixed by commit(s) c93a9b1

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<--------

@jmorse
Copy link
Member Author

jmorse commented Dec 10, 2018

assigned to @jmorse

@jmorse
Copy link
Member Author

jmorse commented Feb 19, 2019

Candidate patch: https://reviews.llvm.org/D58403

@jmorse
Copy link
Member Author

jmorse commented Dec 11, 2019

Fixed in rGc93a9b15ce88

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla wrong-debug
Projects
None yet
Development

No branches or pull requests

1 participant