Plumb in salvaging for the address part of dbg.assign intrinsics.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
1823 | Please use PoisonValue for placeholder/dummy values. We are trying to get rid of undef. |
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. |
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
1823 | Traditionally all placeholders were undef, because there was no poison value. 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. |
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 |
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. |
llvm/lib/Transforms/Utils/Local.cpp | ||
---|---|---|
1823 |
Sure, as long as it doesn't go to the part of the todo list that is never 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 |
Please use PoisonValue for placeholder/dummy values. We are trying to get rid of undef.
Thank you!