[llvm] [StackColoring] Handle SEH catch object stack slots conservatively (PR #66988)

[Reid Kleckner via llvm-commits]

================
@@ -739,14 +695,23 @@ unsigned StackColoring::collectMarkers(unsigned NumSlot) {
     return 0;
   }
 
-  // 1) PR27903: slots with multiple start or end lifetime ops are not
+  // PR27903: slots with multiple start or end lifetime ops are not
   // safe to enable for "lifetime-start-on-first-use".
-  // 2) And also not safe for variable X in catch(X) in windows.
   for (unsigned slot = 0; slot < NumSlot; ++slot) {
-    if (NumStartLifetimes[slot] > 1 || NumEndLifetimes[slot] > 1 ||
-        (NumLoadInCatchPad[slot] > 1 && !StoreSlots.test(slot)))
+    if (NumStartLifetimes[slot] > 1 || NumEndLifetimes[slot] > 1)
       ConservativeSlots.set(slot);
   }
+
+  // The write to the catch object by the personality function is not propely
+  // modeled in IR: It happens before any cleanuppads are executed, even if the
----------------
rnk wrote:

I think proper modelling would mean passing the catch object as a bundled argument to every invoke that unwinds to the catchpad. Every invoke would mention all catch objects of every catch it could unwind to. It would fix the issue, but I worry that the extra clutter would actually make the IR harder for humans to read and understand.

If we find the time to work on the model, catchswitches are another area for improvement. At the time, we didn't have `callbr`, so we added `catchswitch` as an unwind edge multiplexer. Having multiple successor edges coming off of an invoke which unwinds to a catchswitch serving multiple catch blocks is more accurate, and would eliminate BBs with no insertion point, which are an ongoing source of WinEH bugs.

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