[semantic-arc-opts] Eliminate unneeded use of bisection that caused ASAN to fire.

I was being too clever here and in the process of "foot-gunned"
myself. Specifically, I was hoping to use bisection to do some is contained in
list tests. But the list that I actually bisected upon was not the original list
and was just based on the original sorted list! So the pointer comparison for
the bisect no longer worked. Since the bisection was on pointer addresses, if we
were lucky and the new addresses in the new array were sorted the same as the
original array, we wouldn't hit anything.

rdar://60262326

Author: gottesmm

lib/SILOptimizer/Transforms/SemanticARCOpts.cpp

@@ -884,10 +884,6 @@ bool SemanticARCOptVisitor::performPostPeepholeOwnedArgElimination() {
       continue;
     }
 
-    // Then sort the incoming value operand list so that we can bisect search
-    // it.
-    sort(incomingValueOperandList);
-
     // Grab our list of introducer values paired with this SILArgument. See if
     // all of these introducer values were ones that /could/ have been
     // eliminated if it was not for the given phi. If all of them are, we can
@@ -936,8 +932,8 @@ bool SemanticARCOptVisitor::performPostPeepholeOwnedArgElimination() {
         // cvi is one of our originalIncomingValues. If so, we need to set
         // originalIncomingValues to be cvi->getOperand(). Otherwise, weirdness
         // results since we are deleting one of our stashed values.
-        auto iter = lower_bound(originalIncomingValues, cvi);
-        if (iter != originalIncomingValues.end() && *iter == cvi) {
+        auto iter = find(originalIncomingValues, cvi);
+        if (iter != originalIncomingValues.end()) {
           // We use an auxillary array here so we can continue to bisect on
           // original incoming values. Once we are done processing here, we will
           // not need that property anymore.