[PATCH] D75650: [x86][slh] NFC: Rm redundant liveness check

[Zola Bridges via Phabricator via llvm-commits]

zbrid created this revision.
zbrid added reviewers: craig.topper, gbiv, jyknight.
Herald added subscribers: llvm-commits, hiraditya.
Herald added a reviewer: george.burgess.iv.
Herald added a project: LLVM.

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*


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D75650

Files:
  llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp


Index: llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp
===================================================================
--- llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp
+++ llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp
@@ -1203,6 +1203,8 @@
 /// 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.
@@ -1347,19 +1349,6 @@
   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:
@@ -1402,6 +1391,8 @@
 /// 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.
@@ -1516,19 +1507,6 @@
   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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D75650.248334.patch
Type: text/x-patch
Size: 2979 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200304/cb4ab41c/attachment.bin>