[llvm] [DebugInfo] Handle additional types of stores in assignment tracking (PR #129070)

[Stephen Tozer via llvm-commits]

================
@@ -2123,6 +2183,25 @@ getUntaggedStoreAssignmentInfo(const Instruction &I, const DataLayout &Layout) {
   return std::nullopt;
 }
 
+AllocaInst *getUnknownStore(const Instruction &I, const DataLayout &Layout) {
+  auto *II = dyn_cast<IntrinsicInst>(&I);
+  if (!II)
+    return nullptr;
+  Intrinsic::ID ID = II->getIntrinsicID();
+  if (ID != Intrinsic::experimental_vp_strided_store &&
+      ID != Intrinsic::masked_store && ID != Intrinsic::vp_scatter &&
+      ID != Intrinsic::masked_scatter && ID != Intrinsic::vp_store)
+    return nullptr;
+  Value *MemOp = II->getArgOperand(1);
+  // We don't actually use the constant offset for now, but we may in future,
+  // and the non-accumulating versions do not support a vector of pointers.
+  APInt Offset(Layout.getIndexTypeSizeInBits(MemOp->getType()), 0);
+  Value *Base = MemOp->stripAndAccumulateConstantOffsets(Layout, Offset, true);
+  // For Base pointers that are not an alloca instruction we don't need to do
+  // anything, and simply return nullptr.
+  return dyn_cast<AllocaInst>(Base);
----------------
SLTozer wrote:

It isn't a given, but all the examples I've seen *do* store to different offsets at a single alloca though, so I decided not to over-complicate this logic. In practice this is, as far as I can tell, quite a narrowly used intrinsic and the default behaviour of simply ignoring the intrinsic won't cause any errors, so it's probably not worth trying to cover all our bases here until we see this be a problem.

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