DeadStoreElimmination shortens stores that are shadowed by later stores such that the overlapping part of the store is omitted. Insert an unlinked dbg.assign intrinsic with a variable fragment that describes the omitted part to signal that that fragment of the variable has a stale value in memory.
Details
Diff Detail
Event Timeline
If I understand the dse-after-memcpyopt-merge.ll test, the stores after the memset get deleted, because they're effectively done by the memset. However: don't we get the right behaviour with no modifications? There's an assignment of zero to those two fields, and the dbg.assigns record those facts even after the stores are deleted. The location list computed at the end of compilation can rightly say those fields are zero, no?
Same with the second test -- the optimisation is shortening the amount of storing happening, but it isn't optimising away the assignment to those fields, just re-implementing them.
To put it another way -- why is it necessary for those fields to be undef after the shortening of the overlapping stores?
llvm/test/DebugInfo/Generic/assignment-tracking/dse/dse-after-memcpyopt-merge.ll | ||
---|---|---|
11–16 | Probably no need to put a history in the test comment; it isn't a past behaviour that anyone is going to observe, right? |
Good question (another! I very much appreciate this level of review, thank you!). The value component shouldn't need to be undef, but this one is slightly odd because I chose to link the inserted undef dbg.assign to the memset. I think my original intention was to make it "obvious" that the dbg.assign marked the assignment as not-in-memory despite retaining the link. However, a) I'm not convinced that retaining the link is the right thing to do, and b) an undef address component should be enough to signal that the memory location is stale for this fragment if it were.
Yes, thinking about it more, I think we should not retain the DIAssignID link and the value component shouldn't be undef'd. Updated.
LGTM
llvm/test/DebugInfo/Generic/assignment-tracking/dse/dse-after-memcpyopt-merge.ll | ||
---|---|---|
10 |