[PATCH] D49787: [x86/SLH] Significantly optimize the interprocedural hardening strategy.

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc created this revision.
chandlerc added reviewers: echristo, craig.topper.
Herald added subscribers: hiraditya, mcrosier, sanjoy.

Previously, SLH would pedantically thread the predicate state in and out
of the stack pointer around every single call. This is unnecessary, and
there are vague indications it is fairly expensive.

Instead, observe a few things:

1. We can be lazy about restoring the predicate state from the stack pointer until we need it to do some hardening.
2. Once we have put the predicate state for a basic block into the stack pointer, that predicate state never changes due to code *in* that basic block. All subsequent updates within the basic block's execution occur inside of called functions and are communicated back to the block *in the stack pointer*. So once we first merge our predicate state into the stack pointer in a basic block, the most current state remains in the stack pointer for the rest of the block. We can completely skip subsequent merges into the stack pointer.
3. If we already have the predicate state in the stack pointer when we see a return, that may be sufficient to harden the return. This is still being checked, so is currently disabled by a flag.

I'm hopeful this will somewhat help with the instruction density
overhead of SLH, and significantly help benchmarks and applications
where there are tight long chains of calls. I haven't yet gotten
performance data with this optimization in place, but once I do I will
update all of the documentation.


Repository:
  rL LLVM

https://reviews.llvm.org/D49787

Files:
  llvm/lib/Target/X86/X86SpeculativeLoadHardening.cpp
  llvm/test/CodeGen/X86/speculative-load-hardening-indirect.ll
  llvm/test/CodeGen/X86/speculative-load-hardening.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D49787.157230.patch
Type: text/x-patch
Size: 27625 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180725/7e19277a/attachment.bin>