[compiler-rt] [llvm] [RISC-V][Zicfiss] Move shadow stack ops to save/restore builtins (PR #222850)

[Nemanja Ivanovic via llvm-commits]

nemanjai wrote:

Please note: I did not modify the SW shadow stack implementation since it isn't broken (in terms of correctness). However, it could presumably improve in terms of code size similarly to how the HW version improves (by moving the extra saves and restores to the builtins and not emitting them in every prologue/epilogue). However, I am not sure if there's a macro for the SW SS or if it would have to be separate builtins.

In any case, this is one proposed direction for resolving this issue. It does encounter limitations in that it really doesn't allow an application to be built where the save-restore is completely disjoint from `-fcf-protection=return`. Namely, in the following situation:
```
obj1.o - built with -fcf-protection=return, no save-restore
obj2.o - built with -fcf-protection=return, save-restore
obj3.o - built without -fcf-protection=return, save-restore
compiler-rt built with -fcf-protection => we have shadow stack protection in all objects (i.e. it's forced on in obj3.o)
compiler-rt built without -fcf-protection => we have shadow stack protection only in obj1.o
```
Furthermore, any application using save-restore is simply subject to how `compiler-rt` is built wrt. `-fcf-protection=return` rather than how the application itself is built.
However, I personally find this a reasonable compromise since the standard recommends that the linker reject attempts to link objects with differences in terms of their use of the `Zicfiss` extension.

Of course, if the consensus is that this compromise is not acceptable, I think we can still resolve this problem in a couple of ways:
1. Big hammer: disable the combination of `-fcf-protection=return +save-restore`
2. Implement additional builtins that the compiler can call depending on `-fcf-protection=return`
3. Remove saving/restoring the link register from the save/restore builtins

Finally, I believe that both the implementation I proposed in this patch and options 2. and 3. above require alignment between LLVM and GCC.

https://github.com/llvm/llvm-project/pull/222850