================
@@ -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:
I think this is probably handled by the loader. Its how it is currently handled
for platforms like Fuchsia and Android when SCS is enabled. I'm not totally
sure on the new spec, but the linked document above makes me think that is the
case with this text:
```
The dynamic loader should activate the use of Zicfiss extension for an
application only if all executables (the application and the dependent
dynamically linked libraries) used by that application use the Zicfiss
extension.
An application that has the Zicfiss extension active may request the dynamic
loader at runtime to load a new dynamic shared object (using dlopen() for
example). If the requested object does not have the Zicfiss attribute then the
dynamic loader, based on its policy (e.g, established by the operating system
or the administrator) configuration, could either deny the request or
deactivate the Zicfiss extension for the application. It is strongly
recommended that the policy enforces a strict security posture and denies the
request.
```
I believe that setting up this memory and initializing the SCS reg would fall
under `activate the use of Zicfiss...`, but I could be wrong.
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
