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

George Burgess IV via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 9 17:17:48 PDT 2020


This revision was automatically updated to reflect the committed changes.
Closed by commit rGbb0ec1daff1b: [x86][slh][NFC] Rm redundant liveness check (authored by george.burgess.iv).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75650/new/

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.249250.patch
Type: text/x-patch
Size: 2979 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200310/5fa5ec39/attachment.bin>


More information about the llvm-commits mailing list