This is an archive of the discontinued LLVM Phabricator instance.

[Assignment Tracking][SROA] Don't un-poison dbg.assigns using multiple loc ops
ClosedPublic

Authored by Orlando on Apr 11 2023, 7:59 AM.

Details

Summary

Some dbg.assigns using poison become un-poisoned in SROA. The reason this happens at all is because dbg.assigns linked to memory intrinsics use poison to indicate they can't describe the stored value, but the value becomes available after some optimisations. This needs reworking eventually, but for now we need to ensure that when it does occur we don't create invalid expressions.

D147312 prevented this occuring when the dbg.assign uses DIArgLists, but that wasn't a complete fix. We also need to ensure we avoid un-poisoning when the existing expression uses more than one location operand (DW_OP_arg, n).

Diff Detail

Event Timeline

Orlando created this revision.Apr 11 2023, 7:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 11 2023, 7:59 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
Orlando requested review of this revision.Apr 11 2023, 7:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 11 2023, 7:59 AM
jmorse accepted this revision.Apr 11 2023, 9:03 AM

LGTM, to refresh my understanding this all becomes necessary because we've lost information during SROA but kept a link with the store, and now there's enough information to re-instate the dbg.assign Value, but it'd require a lot more work for us to get the expression correct so we're just not doing it for the moment?

This revision is now accepted and ready to land.Apr 11 2023, 9:03 AM

LGTM, to refresh my understanding this all becomes necessary because we've lost information during SROA but kept a link with the store, and now there's enough information to re-instate the dbg.assign Value, but it'd require a lot more work for us to get the expression correct so we're just not doing it for the moment?

Exactly. Thanks for the review(s).