[6.0] FieldSensitivePrunedLiveness: Handle conditionality of try_apply defs.
#72453
Conversation
A `try_apply` with indirect out arguments is only a def for those arguments on the success path. Model this by sinking the def-ness of the instruction into the success branch of the try_apply, and introducing a new `DeadToLiveEdge` mode for block liveness which stops propagation of use-before-def conditions into the block that introduced the def. Fixes rdar://118567869.
|
@swift-ci Please test |
| initializeDefBlock(block, span); | ||
| auto defBlock = getDefinedInBlock(node); | ||
| defBlocks.insert(defBlock, span); | ||
| initializeDefBlock(defBlock, span); |
There was a problem hiding this comment.
I am fine fixing this on main in a forthcoming commit.
I find the logic here hides what is actually happening. First getDefinedInBlock(node) has a special case for try_apply and then we have here another special case below for try_apply. Why not just do something conditional on try_apply here. Then it is clear where all of the special case code is. That being said, I see you used getDefinedInBlock later in the patch, so maybe it makes sense to do this... IDK. Just reads weird to me.
There was a problem hiding this comment.
Yeah, I went back and forth on whether to use getDefinedInBlock here. Maybe it's premature, but I was also trying to think about how to systematically handle these sorts of def-on-edge cases if any more come up; if it does then having getDefinedInBlock already be here and used in more than one place seems like a good thing.
try_applydefs. #72452