This is an archive of the discontinued LLVM Phabricator instance.

[Assignment Tracking][SROA] Handle DIArgList in migrateDebugInfo
ClosedPublic

Authored by Orlando on Mar 31 2023, 3:47 AM.

Details

Summary

If the to-be-split dbg.assign has a DIArgList and a new Value has been requested then use a kill-location for the new dbg.assign. We can't simply replace the value component (a DIArgList) with the new Value as that would leave the DIExpression in an invalid state (DW_OP_LLVM_arg operands with no arglist).

This was tripping an assertion in LiveDebugValues in a self hosted build.

Diff Detail

Event Timeline

Orlando created this revision.Mar 31 2023, 3:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 31 2023, 3:47 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
Orlando requested review of this revision.Mar 31 2023, 3:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 31 2023, 3:47 AM
Orlando updated this revision to Diff 509980.Mar 31 2023, 3:52 AM

+ Remove unused metadata from test

jmorse accepted this revision.Mar 31 2023, 4:05 AM

LGTM; could you expand the comment where you set the kill location a little more, to explicitly explain why we can't use the DIArgList. As I understand it, it's because we'd have to compute the value, then start fragmenting it up, which is a large amount of effort for a rare scenario.

This revision is now accepted and ready to land.Mar 31 2023, 4:05 AM

could you expand the comment

Sure, WDYT of this?

// If we've updated the value but the original dbg.assign has an arglist
// then kill it now - we can't use the requested new value.
// We can't replace the DIArgList with the new value as it'd leave
// the DIExpression in an invalid state (DW_OP_LLVM_arg operands without
// an arglist). And we can't keep the DIArgList in case the linked store
// is being split - in which case the DIArgList + expression may no longer
// be computing the correct value.
// This should be a very rare situation as it requires the value being
// stored to differ from the dbg.assign (i.e., the value has been
// represented differently in the debug intrinsic for some reason).
This revision was landed with ongoing or failed builds.Mar 31 2023, 4:39 AM
This revision was automatically updated to reflect the committed changes.