[WinEH] Don't miscompile cleanups which conditionally unwind to caller

A cleanup can have paths which unwind or end up in unreachable.
If there is an unreachable path *and* a path which unwinds to caller,
we would mistakenly inject an unwind path to a catchswitch on the
unreachable path.  This results in a verifier assertion firing because
the cleanup unwinds to two different places: to the caller and to the
catchswitch.

This occured because we used getCleanupRetUnwindDest to determine if the
cleanuppad had no cleanuprets.
This is incorrect, getCleanupRetUnwindDest returns null for cleanuprets
which unwind to caller.

llvm-svn: 258651

1 files changed, 2 insertions, 1 deletions

diff --git a/llvm/lib/CodeGen/WinEHPrepare.cpp b/llvm/lib/CodeGen/WinEHPrepare.cpp
index c4eaef88673..12733acf3b8 100644
--- a/llvm/lib/CodeGen/WinEHPrepare.cpp
+++ b/llvm/lib/CodeGen/WinEHPrepare.cpp
@@ -1072,7 +1072,8 @@ void WinEHPrepare::fixupNoReturnCleanupPads(Function &F) {
     if (!CleanupPad)
       continue;
     // Skip over any cleanups have unwind targets, they do not need this.
-    if (getCleanupRetUnwindDest(CleanupPad) != nullptr)
+    if (any_of(CleanupPad->users(),
+               [](const User *U) { return isa<CleanupReturnInst>(U); }))
       continue;
     // Walk the blocks within the cleanup which end in 'unreachable'.
     // We will replace the unreachable instruction with a cleanupret;