[PATCH] D147431: [Assignment Tracking][SROA] Handle createFragmentExpression failure

[Orlando Cazalet-Hyams via Phabricator via llvm-commits]

Orlando added a comment.

> I'm curious - why is this value not poison? I'm assuming it's the upper fragment for the dbg.assign that couldn't be split, so I'd have thought it would be a kill location as well.

Good question. It turns out it //is// poison in the call to `migrateDebugInfo` when the store is split, but then in another call to `migrateDebugInfo` later the poison value gets replaced. Nice spot.

The easy fix is to preserve poison-ness of the dbg.assign. However, a dbg.assign linked to a memcpy will have a poison value component. If SROA replaces that memcpy with stores the behaviour at the moment is to replace the poison with the stored-value.

The underlying issue here for both the original issue I was fixing and this poison situation is that the dbg.assign value isn't represented in the same way as the stored value. I think the fix for the original issue makes sense, the "easy fix" mention above also makes sense, and it's the memcpy-linked dbg.assign value representation that doesn't quite fit.

Not quite sure how to solve this just yet - ideas are welcome!



================
Comment at: llvm/test/DebugInfo/Generic/assignment-tracking/sroa/fail-fragment.ll:11
+; CHECK: call void @llvm.dbg.value(metadata i32 poison, metadata ![[#]], metadata !DIExpression(DW_OP_LLVM_fragment, 0, 32))
+; CHECK: call void @llvm.dbg.value(metadata i32 %{{.*}}, metadata ![[#]], metadata !DIExpression(DW_OP_LLVM_fragment, 32, 32))
+
----------------
StephenTozer wrote:
> I'm curious - why is this value //not// poison? I'm assuming it's the upper fragment for the dbg.assign that couldn't be split, so I'd have thought it would be a kill location as well.
(replying with a main-line comment)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147431/new/

https://reviews.llvm.org/D147431