When sinking an instruction in InstCombine we now also sink
the DbgInfoIntrinsics that are using the sunken value.
Example)
When sinking the load in this input
bb.X: %0 = load i64, i64* %start, align 4, !dbg !31 tail call void @llvm.dbg.value(metadata i64 %0, ...) br i1 %cond, label %for.end, label %for.body.lr.ph for.body.lr.ph: br label %for.body we now also move the dbg.value, like this bb.X: br i1 %cond, label %for.end, label %for.body.lr.ph for.body.lr.ph: %0 = load i64, i64* %start, align 4, !dbg !31 tail call void @llvm.dbg.value(metadata i64 %0, ...) br label %for.body In the past we haven't moved the dbg.value so we got bb.X: tail call void @llvm.dbg.value(metadata i64 %0, ...) br i1 %cond, label %for.end, label %for.body.lr.ph for.body.lr.ph: %0 = load i64, i64* %start, align 4, !dbg !31 br label %for.body
So in the past we got a debug-use before the def of %0.
And that dbg.value was also on the path jumping to %for.end, for
which %0 never was defined.
CodeGenPrepare normally comes to rescue later (when not moving
the dbg.value), since it moves dbg.value instrinsics quite
brutally, without really analysing if it is correct to move
the intrinsic (see PR31878).
So at the moment this patch isn't expected to have much impact,
besides that it is moving the dbg.value already in opt, making
the IR look more sane directly.
This can be seen as a preparation to (hopefully) make it possible
to turn off CodeGenPrepare::placeDbgValues later as a solution
to PR31878.
I also adjusted test/DebugInfo/X86/sdagsplit-1.ll to make the
IR in the test case up-to-date with this behavior in InstCombine.