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) &&
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));
}
; 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.