This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Sink related dbg users when sinking in InstCombine
ClosedPublic

Authored by bjope on Apr 9 2018, 2:04 AM.

Details

Summary

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.

Diff Detail

Event Timeline

bjope created this revision.Apr 9 2018, 2:04 AM
bjope added a reviewer: rnk.Apr 10 2018, 6:22 AM
mattd added a subscriber: mattd.Apr 14 2018, 10:46 AM
aprantl edited the summary of this revision. (Show Details)Apr 17 2018, 8:24 AM
aprantl accepted this revision.Apr 17 2018, 8:26 AM

As long as the sunken load retains the same DILocation sinking the dbg.value with it should be correct.

Thanks!

This revision is now accepted and ready to land.Apr 17 2018, 8:26 AM
vsk accepted this revision.Apr 17 2018, 9:48 AM

Thanks, lgtm.

One possible follow-up would be to check for debug info use-before-defs in the verifier, if we aren't already.

This revision was automatically updated to reflect the committed changes.
In D45425#1069936, @vsk wrote:

Thanks, lgtm.

One possible follow-up would be to check for debug info use-before-defs in the verifier, if we aren't already.

The verifier does not catch that today.
There is even a test case verifying that it is OK to have use-before-def, test/Transforms/Inline/local-as-metadata-undominated-use.ll, and it has a comment like this:

; Make sure the inliner doesn't crash when a metadata-bridged SSA operand is an
; undominated use.
;
; If we ever add a verifier check to prevent the scenario in this file, it's
; fine to delete this testcase.  However, we would need a bitcode upgrade since
; such historical IR exists in practice.

There is also a PR27273 (indicating that there have been some attempts in the past by @dexonsmith to enable this kind of verification): https://bugs.llvm.org/show_bug.cgi?id=27273

So I don't know how big the problem is. I think that it would be nice to at least have an option to turn on the check in the verifier, to make it easier to track down this kind of problems.