This was the portion split off D58632 so that it could follow the redzone API cleanup. Note that I changed the offset preferred from -8 to -64. The difference should be very minor, but I thought it might help address one concern which had been previously raised.
Details
Details
- Reviewers
jfb craig.topper - Commits
- rZORGa75df0b74b21: Use an offset from TOS for idempotent rmw locked op lowering
rZORG83a463edabf8: Use an offset from TOS for idempotent rmw locked op lowering
rGa75df0b74b21: Use an offset from TOS for idempotent rmw locked op lowering
rG83a463edabf8: Use an offset from TOS for idempotent rmw locked op lowering
rG445f942fc498: Use an offset from TOS for idempotent rmw locked op lowering
rL360719: Use an offset from TOS for idempotent rmw locked op lowering
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
26282 ↗ | (On Diff #199288) | I think the usual name here would be either TFI or TFL. The type returned is a derived class of TargetFrameLowering. |
Comment Actions
One question for Chandler (which can be addressed as a follow up), otherwise LGTM.
test/CodeGen/X86/speculative-load-hardening.ll | ||
---|---|---|
1148 ↗ | (On Diff #199372) | I only just thought about this: should we stick to mfence when the function has attribute speculative_load_hardening? mfence forces much stronger ordering, and doesn't perform an idempotent load / store from the stack (which in this case brings in a new cacheline). Maybe @chandlerc should chime in. |