[all-commits] [llvm/llvm-project] 2caf85: [ARM] implement LOAD_STACK_GUARD for remaining tar...
Ard Biesheuvel via All-commits
all-commits at lists.llvm.org
Mon Nov 8 14:04:33 PST 2021
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 2caf85ad7ab83c441cb8e3550916d7028dfb8525
https://github.com/llvm/llvm-project/commit/2caf85ad7ab83c441cb8e3550916d7028dfb8525
Author: Ard Biesheuvel <ardb at google.com>
Date: 2021-11-08 (Mon, 08 Nov 2021)
Changed paths:
M llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
M llvm/lib/Target/ARM/ARMISelLowering.cpp
M llvm/lib/Target/ARM/ARMInstrInfo.cpp
M llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
M llvm/test/CodeGen/ARM/ssp-data-layout.ll
M llvm/test/CodeGen/ARM/stack-guard-reassign.ll
M llvm/test/CodeGen/ARM/struct_byval.ll
M llvm/test/CodeGen/ARM/tail-call-scheduling.ll
M llvm/test/CodeGen/ARM/win32-ssp.ll
Log Message:
-----------
[ARM] implement LOAD_STACK_GUARD for remaining targets
Currently, LOAD_STACK_GUARD on ARM is only implemented for Mach-O targets, and
other targets rely on the generic support which may result in spilling of the
stack canary value or address, or may cause it to be kept in a callee save
register across function calls, which means they essentially get spilled as
well, only by the callee when it wants to free up this register.
So let's implement LOAD_STACK GUARD for other targets as well. This ensures
that the load of the stack canary is rematerialized fully in the epilogue.
This code was split off from
D112768: [ARM] implement support for TLS register based stack protector
for which it is a prerequisite.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D112811
More information about the All-commits
mailing list