[x86/SLH] Clean up helper naming for return instruction handling and remove dead declaration of a call instruction handling helper.

[chandlerc]

Summary

This moves to the 'harden' terminology that I've been trying to settle
on for returns. It also adds a really detailed comment explaining what
all we're trying to accomplish with return instructions and why.
Hopefully this makes it much more clear what exactly is being
"hardened".

[echristo]

LGTM. The comment is particularly helpful, thanks!

llvm/trunk/lib/Target/X86/X86SpeculativeLoadHardening.cpp

private:
   hardenLoadAddr(MachineInstr &MI, MachineOperand &BaseMO,
                  MachineOperand &IndexMO,
                  SmallDenseMap<unsigned, unsigned, 32> &AddrRegToHardenedReg);
   MachineInstr *
   sinkPostLoadHardenedInst(MachineInstr &MI,
                            SmallPtrSetImpl<MachineInstr *> &HardenedInstrs);
   bool canHardenRegister(unsigned Reg);
   void hardenPostLoad(MachineInstr &MI);
-  void checkReturnInstr(MachineInstr &MI);
-  void checkCallInstr(MachineInstr &MI);
+  void hardenReturnInstr(MachineInstr &MI);
 };
 
 } // end anonymous namespace
 
 char X86SpeculativeLoadHardeningPass::ID = 0;
 
 void X86SpeculativeLoadHardeningPass::getAnalysisUsage(
     AnalysisUsage &AU) const {
if (HardenInterprocedurally)
     for (MachineBasicBlock &MBB : MF) {
       if (MBB.empty())
         continue;
 
       MachineInstr &MI = MBB.back();
       if (!MI.isReturn())
         continue;
 
-      checkReturnInstr(MI);
+      hardenReturnInstr(MI);
     }
 
   LLVM_DEBUG(dbgs() << "Final speculative load hardened function:\n"; MF.dump();
              dbgs() << "\n"; MF.verify(this));
   return true;
 }
 
 /// Implements the naive hardening approach of putting an LFENCE after every
void X86SpeculativeLoadHardeningPass::hardenPostLoad(MachineInstr &MI) {
   }
 
   if (FlagsReg)
     restoreEFLAGS(MBB, InsertPt, Loc, FlagsReg);
 
   ++NumPostLoadRegsHardened;
 }
 
-void X86SpeculativeLoadHardeningPass::checkReturnInstr(MachineInstr &MI) {
+/// Harden a return instruction.
+///
+/// Returns implicitly perform a load which we need to harden. Without hardening
+/// this load, an attacker my speculatively write over the return address to
+/// steer speculation of the return to an attacker controlled address. This is
+/// called Spectre v1.1 or Bounds Check Bypass Store (BCBS) and is described in
+/// this paper:
+/// https://people.csail.mit.edu/vlk/spectre11.pdf
+///
+/// We can harden this by introducing an LFENCE that will delay any load of the
+/// return address until prior instructions have retired (and thus are not being
+/// speculated), or we can harden the address used by the implicit load: the
+/// stack pointer.
+///
+/// If we are not using an LFENCE, hardening the stack pointer has an additional
+/// benefit: it allows us to pass the predicate state accumulated in this
+/// function back to the caller. In the absence of a BCBS attack on the return,
+/// the caller will typically be resumed and speculatively executed due to the
+/// Return Stack Buffer (RSB) prediction which is very accurate and has a high
+/// priority. It is possible that some code from the caller will be executed
+/// speculatively even during a BCBS-attacked return until the steering takes
+/// effect. Whenever this happens, the caller can recover the (poisoned)
+/// predicate state from the stack pointer and continue to harden loads.
+void X86SpeculativeLoadHardeningPass::hardenReturnInstr(MachineInstr &MI) {
   MachineBasicBlock &MBB = *MI.getParent();
   DebugLoc Loc = MI.getDebugLoc();
   auto InsertPt = MI.getIterator();
 
   if (FenceCallAndRet) {
     // Simply forcibly block speculation of loads out of the function by using
     // an LFENCE. This is potentially a heavy-weight mitigation strategy, but
     // should be secure, is simple from an ABI perspective, and the cost can be