Weird that they would be doing something modifying stack frame layout without knowing about `-msave-restore`, which all RISC-V code except the absolutely most speed-critical should be using, as it not only saves a couple of percent on code size but also makes code faster by making the L1 code cache more effective. I've found for example that even something as small as Coremark is 3% faster on a machine with 16 KB L1 cache when using `-msave-restore` (despite the three extra control flow instructions in each function call/return)
Incidentally, I'm not aware of anything in the ABI that specifies where in the stack frame either the old PC (`ra`) or `s0` should be stored. Is this even guaranteed to stay the same from version to version of GCC, or with different options? If anyone has a reference to such a spec please let me know.
I'm really not in favour of making code bigger and slower by forcing a frame pointer anyway. Stack unwind and backtrace is very rare and doesn't have to be high performance, so I can't see any reason why it shouldn't be done using metadata instead of code in every function. Even in embedded it's not hard to dump the entire stack back to a bigger machine that has access to the full ELF file for analysis.
Incidentally, I'm not aware of anything in the ABI that specifies where in the stack frame either the old PC (`ra`) or `s0` should be stored. Is this even guaranteed to stay the same from version to version of GCC, or with different options? If anyone has a reference to such a spec please let me know.
I'm really not in favour of making code bigger and slower by forcing a frame pointer anyway. Stack unwind and backtrace is very rare and doesn't have to be high performance, so I can't see any reason why it shouldn't be done using metadata instead of code in every function. Even in embedded it's not hard to dump the entire stack back to a bigger machine that has access to the full ELF file for analysis.