[PATCH] D133315: [Assignment Tracking][20/*] Account for assignment tracking in DSE

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

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?



================
Comment at: llvm/test/DebugInfo/Generic/assignment-tracking/dse/dse-after-memcpyopt-merge.ll:10-15
+;; a later store that overwrites part of it. The first attempt at handling
+;; shortened stores in DSE was to split the fragments of the dbg.assigns linked
+;; to the shortened store. However, there may be multile dbg.assigns that only
+;; describe a part of the store each, so now we insert a dbg.assign(..., undef)
+;; after each overlapping fragment to undef the dead part without needing to
+;; work out how to split the fragments exactly.
----------------
Probably no need to put a history in the test comment; it isn't a past behaviour that anyone is going to observe, right?


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

https://reviews.llvm.org/D133315