[compiler-rt][RISC-V] Save/Restore for E goes with ABI

[lenary]

When compiling for the ILP32E/LP64E ABIs, even on a RISC-V machine with
i, we should be using the ILP32E/LP64E save/restore routines, so use
the right preprocessor macro.

---

Previous Description Below:

This makes two significant changes, which I believe are both bugfixes.

• When compiling for the ILP32E/LP64E ABIs, even on a RISC-V machine with i, we should be using the ILP32E/LP64E save/restore routines, so use the right preprocessor macro.
• Saves/restores registers in batches that match the stack alignment for the ILP32E/LP64E ABIs, rather than the larger batches of the conventional ABIs. The implementations of the save routines are not tail-shared, to reduce the number of instructions. I think this also helps code size but I need to check this again.

I would expect (but haven't measured) that the majority of functions compiled for the ILP32E/LP64E ABIs will in fact use both callee-saved registers, and therefore there are still savings to be had, but I think those can come later, with more data (especially if those changes are just to the instruction sequences we use to save the registers, rather than the number and alignment of how this is done).

From what I can tell, this matches the CFI information that both clang and GCC emit: https://godbolt.org/z/ozY3z8Yx5

[lenary]

This is a follow up to fix code added in #88252. Adding those reviewers too.

[jrtc27]

libgcc is as our compiler-rt is today. Switching to look at the ABI not the ISA makes sense to me, and sounds like an oversight in GCC that got mirrored to LLVM (after all, it's an unusual combination to use), but we need to match GCC's ABI for RVE save/restore libcalls, which is to always save all three registers.

[lenary]

I'll split this into two PRs, one for the preprocessor macro, one for the changes to grouping.

My feeling is that there is no specifically-intentional grouping for ilp32e/lp64e given these bugs (it was an oversight by the original implementers), but I realise that also doesn't mean we can retroactively change the grouping, and it may just be that we need to change the CFI we emit instead (and file the same two bugs against GCC). New PR for changing the grouping will be posted momentarily.

[lenary]

#95398 Is the other half of the Split, with the more controversial changes.

[jrtc27]

(Though I believe the title is a bit outdated)

[rOptimizer]

Please notice, that gcc behaves differently with -march=rv32e and it then matches it's library implementation.
See https://godbolt.org/z/WdTnrWj8T

[jrtc27]

Yes, as discussed in https://discourse.llvm.org/t/stack-frame-on-risc-v-with-rve32-and-save-restore/79546/7

[kito-cheng]

LGTM, I believe it's right change, and I know there is some strange situations will use rv32i/rv64i with ilp32e/lp64e ABI...