[llvm] Improvements to RS4GC BDV Algorithm (PR #69795)

[via llvm-commits]

================
@@ -1012,8 +1012,44 @@ static Value *findBasePointer(Value *I, DefiningValueMapTy &Cache,
   }
 #endif
 
-  // Handle all instructions that have a vector BDV, but the instruction itself
-  // is of scalar type.
+  // Even though we have identified a concrete base (or a conflict) for all live
+  // pointers at this point, there are cases where the base is of an
+  // incompatible type compared to the original instruction. We conservatively
+  // mark those as conflicts to ensure that corresponding BDVs will be generated
+  // in the next steps
+
+  // this is a rather explicit check for all cases where we should mark the
+  // state as a conflict to force the latter stages of the algorithm to emit
+  // the BDVs. Note that the IE and EE instruction check is not fully subsumed
+  // by the vector<->scalar check at the end, this is due to the BDV algorithm
+  // being ignorant of BDV types at this junction
+  // TODO: in many cases the instructions emited for the conflicting states
+  // will be identical to the I itself (if the I's operate on their BDVs
+  // themselves). We should expoit this, but can't do it here since it would
+  // break the invariant about the BDVs not being known to be a base.
+  // TODO: the code also does not handle constants at all - the algithm relies
+  // on all constants having the same BDV and therefore constant-only insns
+  // will never be in conflict, but this check is ignored here. If the
+  // constant conflicts will be to BDVs themselves, they will be identical
+  // instructions and will get optimized away (as in the above TODO)
+  auto MarkConflict = [&](Instruction *I, Value *BaseValue) {
+    // II mixes vector & scalar so is always a conflict
+    if (isa<InsertElementInst>(I))
+      return true;
+    // EE mixes vector and scalar so is always conflict
+    if (isa<ExtractElementInst>(I))
+      return true;
+    // shuffle vector is always conflict as it creates new vector from existing
+    // ones
+    if (isa<ShuffleVectorInst>(I))
+      return true;
+    // any other insns that change from vector to scalar are marked to be on
----------------
annamthomas wrote:

I'd state more explicitly (since it is not just any instructions which convert from scalar to vector or vice-versa).

```suggestion
    // Any  instructions where the computed base type differs from the instruction type. An example is
    //  where an extract instruction is used by a select. Here the select's BDV is a vector (because of extract's 
    // BDV), while the select itself is a scalar type.
```
Also, pls move the comment (note) to this line about why the above explicit checks are not subsumed by this one. 

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