[llvm] r236248 - Don't rewrite jumps to empty BBs to landing pads.

[Pete Cooper]

Author: pete
Date: Thu Apr 30 13:58:23 2015
New Revision: 236248

URL: http://llvm.org/viewvc/llvm-project?rev=236248&view=rev
Log:
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

Added:
    llvm/trunk/test/CodeGen/X86/branchfolding-landingpads.ll
Modified:
    llvm/trunk/lib/CodeGen/BranchFolding.cpp

Modified: llvm/trunk/lib/CodeGen/BranchFolding.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/BranchFolding.cpp?rev=236248&r1=236247&r2=236248&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/BranchFolding.cpp (original)
+++ llvm/trunk/lib/CodeGen/BranchFolding.cpp Thu Apr 30 13:58:23 2015
@@ -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.

Added: llvm/trunk/test/CodeGen/X86/branchfolding-landingpads.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/branchfolding-landingpads.ll?rev=236248&view=auto
==============================================================================
--- llvm/trunk/test/CodeGen/X86/branchfolding-landingpads.ll (added)
+++ llvm/trunk/test/CodeGen/X86/branchfolding-landingpads.ll Thu Apr 30 13:58:23 2015
@@ -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 }
+