From: Pete Cooper <peter_cooper@apple.com>
Date: Thu, 30 Apr 2015 18:58:23 +0000 (+0000)
Subject: Don't rewrite jumps to empty BBs to landing pads.
X-Git-Tag: llvmorg-3.7.0-rc1~5608
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=4d8d2ec3ebf2334e8f16b4d702e3e6e6788c4a3e;p=platform%2Fupstream%2Fllvm.git

Don't rewrite jumps to empty BBs to landing pads.

In the test case here, the 'unreachable' BB was removed by BranchFolding because its empty.

It then rewrote the jump from 'entry' to jump to its fallthrough, which was a landing pad.

This results in 'entry' jumping to 2 different landing pads, which fails the machine verifier.

rdar://problem/20750162

llvm-svn: 236248
---

diff --git a/llvm/lib/CodeGen/BranchFolding.cpp b/llvm/lib/CodeGen/BranchFolding.cpp
index abe7ca1..3b22d31 100644
--- a/llvm/lib/CodeGen/BranchFolding.cpp
+++ b/llvm/lib/CodeGen/BranchFolding.cpp
@@ -1203,6 +1203,11 @@ ReoptimizeBlock:
 
     if (FallThrough == MF.end()) {
       // TODO: Simplify preds to not branch here if possible!
+    } else if (FallThrough->isLandingPad()) {
+      // Don't rewrite to a landing pad fallthough.  That could lead to the case
+      // where a BB jumps to more than one landing pad.
+      // TODO: Is it ever worth rewriting predecessors which don't already
+      // jump to a landing pad, and so can safely jump to the fallthrough?
     } else {
       // Rewrite all predecessors of the old block to go to the fallthrough
       // instead.
diff --git a/llvm/test/CodeGen/X86/branchfolding-landingpads.ll b/llvm/test/CodeGen/X86/branchfolding-landingpads.ll
new file mode 100644
index 0000000..40ec92e
--- /dev/null
+++ b/llvm/test/CodeGen/X86/branchfolding-landingpads.ll
@@ -0,0 +1,45 @@
+; RUN: llc %s -o - -verify-machineinstrs | FileCheck %s
+
+target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-unknown"
+
+; The machine level BranchFolding pass will try to remove the 'unreachable' block
+; and rewrite 'entry' to jump to the block 'unreachable' falls through to.
+; That will be a landing pad and result in 'entry' jumping to 2 landing pads.
+; This tests that we don't do this change when the fallthrough is itself a landing
+; pad.
+
+declare i32 @__gxx_personality_v0(...)
+declare void @foo()
+
+; Function Attrs: noreturn
+declare void @_throw()
+
+; CHECK-LABEL: @main
+; CHECK: %unreachable
+
+define i32 @main(i8* %cleanup) {
+entry:
+  invoke void @_throw() #0
+          to label %unreachable unwind label %catch.dispatch9
+
+catch.dispatch9:                                  ; preds = %entry
+  %tmp13 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)
+          cleanup
+          catch i8* null
+  invoke void @_throw() #0
+          to label %unreachable unwind label %lpad31
+
+lpad31:                                           ; preds = %catch.dispatch9
+  %tmp20 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*)
+          cleanup
+          catch i8* null
+  call void @foo()
+  unreachable
+
+unreachable:                                      ; preds = %catch.dispatch9, %entry
+  unreachable
+}
+
+attributes #0 = { noreturn }
+