[llvm] [DSE] Stop double-counting the dead slice offset in shortenAssignment (PR #216227)

[Eric Christopher via llvm-commits]

================
@@ -0,0 +1,90 @@
+; RUN: opt %s -S -passes=dse -o - | FileCheck %s --implicit-check-not="#dbg_"
+
+;; The IR is clang's, with only the cleanup listed below. The variable fills its
+;; alloca, so the source byte offsets can be checked directly against the test.
+;;
+;; $ cat shorten.c
+;; void esc(char *);
+;; void shortenBeginPartial(void) {
+;;   char local[80];
+;;   __builtin_memset(local + 8, 0, 72);
+;;   __builtin_memset(local + 4, 8, 64);
+;;   esc(local);
+;; }
+;;
+;; $ clang -O2 -g -gno-key-instructions -c \
+;;       -Xclang -fexperimental-assignment-tracking=forced \
+;;       -mllvm -print-before=dse -mllvm -print-module-scope shorten.c \
+;;       -o /dev/null
+;;
+;; and then, by hand: dropped the target triple and datalayout so this runs
+;; anywhere, dropped the tbaa metadata, llvm.ident, the producer/checksum/
+;; sysroot strings, the lifetime intrinsics and the function attributes, and
+;; renumbered the metadata. The remaining non-debug instructions keep clang's
+;; order and operands, and the assignment offsets are unchanged.
+
+;; 'local' is 640 bits and starts at the alloca, so variable bit N is alloca
+;; byte N/8 throughout, which is what makes the arithmetic readable.
+;;
+;; The first memset covers bytes [8, 80) and the second covers [4, 68), so DSE
+;; shortens the first to [68, 80). The dead slice is [8, 68), or variable bits
+;; [64, 544), which gives fragment (64, 480). Counting the same eight-byte
+;; offset again gives (128, 480). Both fit inside the record's original
+;; (64, 576) fragment, so only the offset exposes the bug. shorten-offset.ll
----------------
echristo wrote:

Agreed. That could have been a lot better comment. 

https://github.com/llvm/llvm-project/pull/216227