================
@@ -106,9 +111,14 @@ static void emitSCSEpilogue(MachineFunction &MF,
MachineBasicBlock &MBB,
CSI, [&](CalleeSavedInfo &CSR) { return CSR.getReg() == RAReg; }))
return;
+ const RISCVInstrInfo *TII = STI.getInstrInfo();
+ if (STI.hasFeature(RISCV::FeatureStdExtZicfiss)) {
----------------
ilovepi wrote:
> What if we're compiling for a platform that only uses the software shadow
> stack and does not support the hardware shadow stack even if the CPU supports
> it?
Today, if you use software SCS on a platform without support they just fail,
since the SCS won't be setup and gp(probably) points to invalid memory. Is it
unreasonable to have it work the same in this case?
WDYT about phrasing this an an opt-out flag, like `-force-software-scs`, and
using a helper function, like :
```
bool enableHWSCS(){ return !ForceSoftwareSCS &&
STI.hasFeature(RISCV::FeatureStdExtZicfiss); }
```
My thinking is that using HW SCS on platforms that have it is a good default,
which we want to encourage, but we can still allow folks to force the software
implementation if they want.
It also occurs to me that X86 is getting/has backward edge CFI, right? how do
we enable that in the x86 backend? How is GCC planning to spell these options,
since I would suppose there needs to be some level of compatibility.
https://github.com/llvm/llvm-project/pull/68075
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
