[x86][slh][NFC] Rm redundant liveness check

[zbrid]

Summary

In this changeset (https://reviews.llvm.org/D70283), I added a liveness
check everywhere the isDataInvariant* functions were used, so that I
could safely delete the checks within the function. I mistakenly left
that deletion out of the patch. The result is that the same condition is
checked twice for some instructions which is functionally fine, but not
good. This change deletes the redundant check that I intended to delete
in the last change.

This is the second of three patches that will make the data invariance
checks available for non-SLH passes and enable the FIXMEs related to
moving this metadata to the instruction tables to be resolved.

Tested via llvm-lit llvm/test/CodeGen/X86/speculative-load-hardening*

[craig.topper]

LGTM

llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp

X86SpeculativeLoadHardeningPass::tracePredStateThroughIndirectBranches(
 
   // Return all the newly inserted cmov instructions of the predicate state.
   return CMovs;
 }
 
 /// Returns true if the instruction has no behavior (specified or otherwise)
 /// that is based on the value of any of its register operands
 ///
+/// Instructions are considered data invariant even if they set EFLAGS.
+///
 /// A classical example of something that is inherently not data invariant is an
 /// indirect jump -- the destination is loaded into icache based on the bits set
 /// in the jump destination register.
 ///
 /// FIXME: This should become part of our instruction tables.
 static bool isDataInvariant(MachineInstr &MI) {
   switch (MI.getOpcode()) {
   default:
static bool isDataInvariant(MachineInstr &MI) {
   // Arithmetic with just 32-bit and 64-bit variants and no immediates.
   case X86::ADCX32rr: case X86::ADCX64rr:
   case X86::ADOX32rr: case X86::ADOX64rr:
   case X86::ANDN32rr: case X86::ANDN64rr:
   // Unary arithmetic operations.
   case X86::DEC8r: case X86::DEC16r: case X86::DEC32r: case X86::DEC64r:
   case X86::INC8r: case X86::INC16r: case X86::INC32r: case X86::INC64r:
   case X86::NEG8r: case X86::NEG16r: case X86::NEG32r: case X86::NEG64r:
-    // Check whether the EFLAGS implicit-def is dead. We assume that this will
-    // always find the implicit-def because this code should only be reached
-    // for instructions that do in fact implicitly def this.
-    if (!MI.findRegisterDefOperand(X86::EFLAGS)->isDead()) {
-      // If we would clobber EFLAGS that are used, just bail for now.
-      LLVM_DEBUG(dbgs() << "    Unable to harden post-load due to EFLAGS: ";
-                 MI.dump(); dbgs() << "\n");
-      return false;
-    }
-
-    // Otherwise, fallthrough to handle these the same as instructions that
-    // don't set EFLAGS.
-    LLVM_FALLTHROUGH;
 
   // Unlike other arithmetic, NOT doesn't set EFLAGS.
   case X86::NOT8r: case X86::NOT16r: case X86::NOT32r: case X86::NOT64r:
 
   // Various move instructions used to zero or sign extend things. Note that we
   // intentionally don't support the _NOREX variants as we can't handle that
   // register constraint anyways.
   case X86::MOVSX16rr8:

 /// Returns true if the instruction has no behavior (specified or otherwise)
 /// that is based on the value loaded from memory or the value of any
 /// non-address register operands.
 ///
 /// For example, if the latency of the instruction is dependent on the
 /// particular bits set in any of the registers *or* any of the bits loaded from
 /// memory.
 ///
+/// Instructions are considered data invariant even if they set EFLAGS.
+///
 /// A classical example of something that is inherently not data invariant is an
 /// indirect jump -- the destination is loaded into icache based on the bits set
 /// in the jump destination register.
 ///
 /// FIXME: This should become part of our instruction tables.
 static bool isDataInvariantLoad(MachineInstr &MI) {
   switch (MI.getOpcode()) {
   default:
static bool isDataInvariantLoad(MachineInstr &MI) {
   case X86::SUB8rm:
   case X86::SUB16rm:
   case X86::SUB32rm:
   case X86::SUB64rm:
   case X86::XOR8rm:
   case X86::XOR16rm:
   case X86::XOR32rm:
   case X86::XOR64rm:
-    // Check whether the EFLAGS implicit-def is dead. We assume that this will
-    // always find the implicit-def because this code should only be reached
-    // for instructions that do in fact implicitly def this.
-    if (!MI.findRegisterDefOperand(X86::EFLAGS)->isDead()) {
-      // If we would clobber EFLAGS that are used, just bail for now.
-      LLVM_DEBUG(dbgs() << "    Unable to harden post-load due to EFLAGS: ";
-                 MI.dump(); dbgs() << "\n");
-      return false;
-    }
-
-    // Otherwise, fallthrough to handle these the same as instructions that
-    // don't set EFLAGS.
-    LLVM_FALLTHROUGH;
 
   // Integer multiply w/o affecting flags is still believed to be constant
   // time on x86. Called out separately as this is among the most surprising
   // instructions to exhibit that behavior.
   case X86::MULX32rm:
   case X86::MULX64rm:
 
   // Arithmetic instructions that are both constant time and don't set flags.