[DebugInfo@O2] CodeGenPrepare address-mode sinking drops dbg.values

[jmorse]

Bugzilla Link	39937
Resolution	INVALID
Resolved on	Dec 10, 2018 10:57
Version	trunk
OS	Linux
Blocks	#38116 #38102
CC	@dwblaikie,@gregbedwell,@CarlosAlbertoEnciso,@pogo59

Extended Description

Using latest trunk (r348754), running the LLVM IR below through "llc -stop-after=codegenprepare" drops the single call to dbg.value un-necessarily. Note the extra branch / basic block: it's contrived in this test to demonstrate the overall problem.

-------->8--------
declare void @​llvm.dbg.value(metadata, metadata, metadata)

define i32 @​lala(i32 %ptr) {
%bees = getelementptr i32, i32 %ptr, i32 4
br label %next

next:
call void @​llvm.dbg.value(metadata i32 *%bees, metadata !​1, metadata !DIExpression())
store i32 1, i32 *%bees
ret i32 1
}

!llvm.module.flags = !{#4}
!​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 following is the shortened output of llc (stopping at CGP):

-------->8--------
define i32 @​lala(i32* %ptr) {
next:
%0 = bitcast i32* %ptr to i8*
%sunkaddr = getelementptr i8, i8* %0, i64 16
%1 = bitcast i8* %sunkaddr to i32*
store i32 1, i32* %1
ret i32 1
}
--------8<--------

CGP has applied two transformations, it sinks the GEP from the first BB into the second (to allow it to be folded into machine addressing modes), after which it merges the two basic blocks. The problem is in the first transformation: the debug user (dbg.value call) of the dereferenced pointer is not updated after the GEP is sunk, leaving it referencing a nonexistant value and ultimately getting dropped. This problem can be decomposed further:

• The dbg.value should have been updated to refer to the sunk GEP
• If that was impossible, a dbg.value(undef...) should have been produced.

I'm seeing this in the context of bug 38754 (the placeDbgValues odyssey), however the problem with the input above replicates with plain trunk.

[jmorse]

assigned to @jmorse

[jmorse]

...aaannndd actually what was happening here was my half-baked debuginfo metadata being wrong, and me missing the warning that LLVM was dropping most of it. Curses, and apologies for the excess noise.

There's still something flaky involving CGPs sinking of addresses: it only RAUW's one Value, and dbg.values can refer to components of the address that aren't the final Value that gets dereferenced. However I'll open a different bug for that, when I get a reproducer that Actually Works (TM).