[MachineSink][NFC] delete some useless code

[shchenz]

Summary

SuccToSinkTo dominates all users of MI, so MI->getParent() must dominate SuccToSinkTo, otherwise there will be use without def issue?

[shchenz]

gentle ping

[nikic]

If I replace this check with an assertion, I get 63 assertion failures in X86 tests.

[shchenz]

In D123993#3473873, @nikic wrote:

If I replace this check with an assertion, I get 63 assertion failures in X86 tests.

Yeah, I also got some assertion failures on PowerPC. They are related to sinking instructions with PHI users. Thanks for the good assertions ways. @nikic

[MatzeB]

For PHI instruction the values have to dominate the end of the predecessor block for the respective PHI input; you don't necessarily have to dominate the PHI itself.

llvm/lib/CodeGen/MachineSink.cpp

if (SuccToSinkTo->pred_size() > 1) {
     bool TryBreak = false;
     bool Store =
         MI.mayLoad() ? hasStoreBetween(ParentBlock, SuccToSinkTo, MI) : true;
     if (!MI.isSafeToMove(AA, Store)) {
       LLVM_DEBUG(dbgs() << " *** NOTE: Won't sink load along critical edge.\n");
       TryBreak = true;
     }
 
-    // We don't want to sink across a critical edge if we don't dominate the
-    // successor. We could be introducing calculations to new code paths.
-    if (!TryBreak && !DT->dominates(ParentBlock, SuccToSinkTo)) {
-      LLVM_DEBUG(dbgs() << " *** NOTE: Critical edge found\n");
-      TryBreak = true;
-    }
-
     // Don't sink instructions into a loop.
     if (!TryBreak && LI->isLoopHeader(SuccToSinkTo)) {
       LLVM_DEBUG(dbgs() << " *** NOTE: Loop header found\n");
       TryBreak = true;
     }
 
     // Otherwise we are OK with sinking along a critical edge.
     if (!TryBreak)