[SimplifyCFG] Update workaround for PR30188 to also include loads

I should have realised this the first time around, but if we're avoiding sinking stores where the operands come from allocas so they don't create selects, we also have to do the same for loads because SROA will be just as defective looking at loads of selected addresses as stores.

Fixes PR30188 (again).

llvm-svn: 280792

llvm/lib/Transforms/Utils/SimplifyCFG.cpp

@@ -1428,8 +1428,8 @@ static bool canSinkInstructions(
         return false;
       }
       // Because SROA can't handle speculating stores of selects, try not
-      // to sink stores of allocas when we'd have to create a PHI for the
-      // address operand.
+      // to sink loads or stores of allocas when we'd have to create a PHI for
+      // the address operand.
       // FIXME: This is a workaround for a deficiency in SROA - see
       // https://llvm.org/bugs/show_bug.cgi?id=30188
       if (OI == 1 && isa<StoreInst>(I0) &&
@@ -1437,6 +1437,11 @@ static bool canSinkInstructions(
             return isa<AllocaInst>(I->getOperand(1));
           }))
         return false;
+      if (OI == 0 && isa<LoadInst>(I0) &&
+          any_of(Insts, [](const Instruction *I) {
+            return isa<AllocaInst>(I->getOperand(0));
+          }))
+        return false;
       for (auto *I : Insts)
         PHIOperands[I].push_back(I->getOperand(OI));
     }

llvm/test/Transforms/SimplifyCFG/sink-common-code.ll

@@ -585,6 +585,35 @@ if.end:
 ; CHECK: store
 ; CHECK: store
 
+define i32 @test_pr30188a(i1 zeroext %flag, i32 %x) {
+entry:
+  %y = alloca i32
+  %z = alloca i32
+  br i1 %flag, label %if.then, label %if.else
+
+if.then:
+  call void @g()
+  %one = load i32, i32* %y
+  %two = add i32 %one, 2
+  store i32 %two, i32* %y
+  br label %if.end
+
+if.else:
+  %three = load i32, i32* %z
+  %four = add i32 %three, 2
+  store i32 %four, i32* %y
+  br label %if.end
+
+if.end:
+  ret i32 1
+}
+
+; CHECK-LABEL: test_pr30188a
+; CHECK-NOT: select
+; CHECK: load
+; CHECK: load
+; CHECK: store
+
 ; The phi is confusing - both add instructions are used by it, but
 ; not on their respective unconditional arcs. It should not be
 ; optimized.