[OperandBundles] Treat "deopt" operand bundles specially

Teach LLVM optimize to more precisely in the presence of "deopt" operand
bundles.  "deopt" operand bundles imply that the call they're attached
to is at least `readonly` (i.e. they don't imply clobber semantics), and
they don't capture their bundle operands.

llvm-svn: 254118

1 files changed, 20 insertions, 2 deletions

diff --git a/llvm/test/Feature/OperandBundles/early-cse.ll b/llvm/test/Feature/OperandBundles/early-cse.ll
index 076ce3baeab..fc201479d8c 100644
--- a/llvm/test/Feature/OperandBundles/early-cse.ll
+++ b/llvm/test/Feature/OperandBundles/early-cse.ll
@@ -2,8 +2,8 @@
 
 ; While it is normally okay to do memory optimizations over calls to
 ; @readonly_function and @readnone_function, we cannot do that if
-; they're carrying operand bundles since the presence of unknown
-; operand bundles implies arbitrary memory effects.
+; they're carrying unknown operand bundles since the presence of
+; unknown operand bundles implies arbitrary memory effects.
 
 declare void @readonly_function() readonly nounwind
 declare void @readnone_function() readnone nounwind
@@ -69,3 +69,21 @@ define void @test5(i32* %x) {
 ; CHECK: store i32 200, i32* %x
   ret void
 }
+
+define void @test6(i32* %x) {
+; The "deopt" operand bundle does not make the call to
+; @readonly_function read-write; and so the nounwind readonly call can
+; be deleted.
+
+; CHECK-LABEL: @test6(
+ entry:
+
+; CHECK-NEXT: entry:
+; CHECK-NEXT:  store i32 200, i32* %x
+; CHECK-NEXT:  ret void
+
+  store i32 100, i32* %x
+  call void @readonly_function() [ "deopt"() ]
+  store i32 200, i32* %x
+  ret void
+}