This is an archive of the discontinued LLVM Phabricator instance.

[Assignment Tracking][10/*] salvageDebugInfo for dbg.assign intrinsics
ClosedPublic

Authored by Orlando on Sep 5 2022, 5:14 AM.

Details

Summary

Plumb in salvaging for the address part of dbg.assign intrinsics.

Diff Detail

Event Timeline

Orlando created this revision.Sep 5 2022, 5:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 5 2022, 5:14 AM
Orlando requested review of this revision.Sep 5 2022, 5:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 5 2022, 5:14 AM
nlopes added inline comments.Sep 5 2022, 5:51 AM
llvm/lib/Transforms/Utils/Local.cpp
1823

Please use PoisonValue for placeholder/dummy values. We are trying to get rid of undef.
Thank you!

Orlando added inline comments.Sep 5 2022, 6:05 AM
llvm/lib/Transforms/Utils/Local.cpp
1823

Oh right, I wasn't aware of that - do you have a link to a discussion on this?

FWIW, this Undef is wrapped in ValueAsMetadata and is used by a debug intrinsic, if that makes a difference. This is currently standard practice for debug intrinsics to denote that the value of a variable is unknown.

I posted a question on discourse that might be relevant / you may be interested in - here.

nlopes added inline comments.Sep 5 2022, 6:11 AM
llvm/lib/Transforms/Utils/Local.cpp
1823

Traditionally all placeholders were undef, because there was no poison value.
But now that we have poison, we are trying to move away from undef. Since PoisonValue inherits from UndefValue, all matchers (e.g., isa<>) will work fine. So upgrades can be done incrementally.

I do have a rule in the review system to alert me when someone is trying to add a new use of UndefValue::get, as we want to avoid that.

jmorse added a subscriber: jmorse.Sep 7 2022, 4:36 AM

LGTM with a question mark over whether we can just start off using poison operands for addresses in dbg.assigns (doing it to the value field makes conformance with the existing dbg.value tests harder). Plus the caveat that to avoid regression, dbg.assign will need to support variadic value operands.

llvm/lib/Transforms/Utils/Local.cpp
1823

@Orlando given that this is a new field that doesn't match existing tests for dbg.value's, will there be much breakage of lit tests if we use Poison here? I think we should prefer to update debug-info use of poison in one fell swoop, but as this is A New Thing (TM) the implications of using poison here should be small, I would imagine.

1853–1854

Doesn't the rest of this function only apply to the Value field, and for DbgAssigns we've already checked whether the Value field contains the instruction? And if it does contain the instruction, this assertion can't fire, surely, so isn't DbgAssignAddrUse redundant?

llvm/test/DebugInfo/Generic/assignment-tracking/salvage-value.ll
2

I'd suggest an implicit check not for other dbg.assigns

Orlando added inline comments.Sep 8 2022, 8:18 AM
llvm/lib/Transforms/Utils/Local.cpp
1823

I see - it definitely makes sense to move debug intrinsics away from using Undef then.

While I would personally prefer that all debug intrinsics are updated at once, so that we have a uniform representation in IR, @jmorse is right that the problem surface area does shrink if we restrict the update to just this field as it is not shared by existing debug intrinsics.

However, I am still worried about the additional risk of potential complications given that the patch stack is already quite large, and I'm probably going to have my hands full dealing with the fallout for some time as it is.

@nlopes, would you be satisfied if removing this use of Undef came as a future patch and is put on this project's TODO-list (see D132220)?

1853–1854

That looks right. This was probably the result of refactoring things at some point.

nlopes added inline comments.Sep 8 2022, 1:52 PM
llvm/lib/Transforms/Utils/Local.cpp
1823

@nlopes, would you be satisfied if removing this use of Undef came as a future patch and is put on this project's TODO-list (see D132220)?

Sure, as long as it doesn't go to the part of the todo list that is never done :)
We are serious about removing undef from LLVM, so we would appreciate help in not adding more users of undef long term. Ofc if it's just something temporary, it's perfectly fine.
Thank you!

Orlando updated this revision to Diff 459007.Sep 9 2022, 3:33 AM
Orlando marked 2 inline comments as done.

+ Address review comments

Plus the caveat that to avoid regression, dbg.assign will need to support variadic value operands.

Is this also something that can be a TODO item, given that the feature is experimental? Similarly to the use of Poison there are no obvious problems that spring to mind, but it would involve further changes and testing (as well as there being the possibility of non-obvious problems lurking).

llvm/lib/Transforms/Utils/Local.cpp
1823

Of course. Thank you @nlopes I appreciate that! Added to the TODO list in the docs in D132220.

jmorse accepted this revision.Sep 14 2022, 3:06 AM

Is this also something that can be a TODO item, given that the feature is experimental? Similarly to the use of Poison there are no obvious problems that spring to mind, but it would involve further changes and testing (as well as there being the possibility of non-obvious problems lurking).

Sure, LGTM.

This revision is now accepted and ready to land.Sep 14 2022, 3:06 AM
This revision was landed with ongoing or failed builds.Nov 9 2022, 3:50 AM
This revision was automatically updated to reflect the committed changes.