This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo][InstrRef] Don't fire assertions if broken debug-info is seen
ClosedPublic

Authored by jmorse on Feb 4 2022, 7:30 AM.

Details

Summary

As reported in https://github.com/llvm/llvm-project/issues/53584 , there are a few lurking optimisations that don't update debug-info when instructions are mutated (a fairly rare event anyway). When this happens, it's nice to get bug reports, but it's even better for the developer to not crash the compiler and instead ignore any broken variable locations.

To that end, convert assertions about instruction references always referring to register definitions into "if" conditions -- when a non-register-def operand is referred to in transferDebugInstrRef, the variable value will remain "None" and become "optimised out" when seen in a debugger.

I've done the same for DBG_PHIs, and that's exposed a more interesting issue: If there's only ever one DBG_PHI for a value, we don't need to do any further work to determine the instruction references value, it's the one referred to by the DBG_PHI. But:

  • If there's more than one DBG_PHI (see value 7 in the added test),
  • and one of them is invalid in some way,
  • We ignore it, leaving a single DBG_PHI recorded, making the instruction reference value be whatever the remaining DBG_PHI refers to.

In the test below (the DBG_PHIs for value number 7, in blocks 1 and 2), that's undesirable because we essentially ignore the illegal side of the branch in favour of the other. A better solution is to accept that the debug-info is broken, and not produce a variable location. I've implemented that by making the value seen by DBG_PHI Optional, recording None values when a broken DBG_PHI is seen, then producing no variable value from resolveDbgPHIs if any were broken.

I've added some LLVM_DEBUG lines to complain if any of these broken values are seen.

Diff Detail

Event Timeline

jmorse created this revision.Feb 4 2022, 7:30 AM
jmorse requested review of this revision.Feb 4 2022, 7:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2022, 7:30 AM
Orlando accepted this revision.Feb 8 2022, 4:19 AM

LGTM. Converting badly-formed variable locations into "no location" rather than crashing the compiler SGTM. Is it worth fixing the defect in the bug report too in a separate patch?

llvm/test/DebugInfo/MIR/InstrRef/livedebugvalues_illegal_locs.mir
4–5

Could you add a sentence to describe the purpose of the test?

This revision is now accepted and ready to land.Feb 8 2022, 4:19 AM

LGTM. Converting badly-formed variable locations into "no location" rather than crashing the compiler SGTM. Is it worth fixing the defect in the bug report too in a separate patch?

Separate patch is best IMO, it'll manifest as a dropped location right now, which is also what fixing the function mentioned in the bug report will do. This also gives more choices when cherry picking to the release branch.

llvm/test/DebugInfo/MIR/InstrRef/livedebugvalues_illegal_locs.mir
4–5

Good point, I'll fold that into the landed verion.

This revision was landed with ongoing or failed builds.Feb 10 2022, 3:25 AM
This revision was automatically updated to reflect the committed changes.