mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-26 04:32:44 +01:00
[x86][slh][NFC] Rm redundant liveness check
Patch by Zola Bridges! From the review: """ 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* """ Differential Revision: https://reviews.llvm.org/D75650
This commit is contained in:
parent
b50c2ca621
commit
ce0e94ade3
@ -1203,6 +1203,8 @@ X86SpeculativeLoadHardeningPass::tracePredStateThroughIndirectBranches(
|
||||
/// 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 @@ static bool isDataInvariant(MachineInstr &MI) {
|
||||
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 @@ static bool isDataInvariant(MachineInstr &MI) {
|
||||
/// 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 @@ static bool isDataInvariantLoad(MachineInstr &MI) {
|
||||
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
|
||||
|
Loading…
Reference in New Issue
Block a user