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

[Nikita Popov 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
----------------
nikic wrote:

Do we expect to see problems in passes other than StackColoring?

The somewhat special situation here is that while the invoke effectively writes to the stack slot, code can only *rely* on that write inside the catchpad. So if we have something like this:
```
*e = x
invoke (unmodeled potential write to e)
cleanuppad
 v = *e
catchpad(e)
```
and then `v = *e` gets GVNd to `x` because the write at the invoke is not modeled, I would not really consider that a miscompile.

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