To handle the variable-sized objects with stack alignment, we need another base register(BP) to record the SP value after realignment. So we could reference the local variables after allocating the variable-sized objects by the base register. To avoid the BP value clobbered by a function call, we need to choose a callee saved register as BP. RV32E only has X8 and X9 as callee saved registers and X8 will be used as FP. So X9 will be chosen as the BP register.
This is looking good. Just a few small comments at the moment, and I'm going to kick off a testing run on our internal build system.
Please may you use getBPReg here instead of hard-coded RISCV::X9?
At some point, we should use getFPReg for everywhere we hard-code RISCV::X2, but that's irrelevant to this change.
Again, use getBPReg here to avoid hard-coding RISCV::X9.
Again, use getBPReg here (if you can, this one is harder)
Shiva, I have tried a few workloads like EEMBC, SPEC2000/2006, perennial c++, plumhall.
They don't seem to use variable length arrays nor allocas to test this patch.
Which test suite are you using?
Thanks for the work. I ran GCC testsuite and gcc.c-torture/compile/pr51354.c will trigger the patch.
I expect rv32e would have little more cases trigger the patch due to smaller stack alignment.
But the cases of variable-sized objects with realignment are not very often.
This doesn't look right. Why does this directive come after the restore of s0 and s1 (but not ra)? Shouldn't it come immediately after the addi instruction?
I think the idea is that before s0 been restored, debugger could use s0 as the base to calculate CFA. After the s0 been corrupted, the CFA calculation has to base on sp with sp_offset. addi sp, s0, -128 will be generated for the frame contains variable-sized objects. For the case has FP but not contains variable-sized objects, the directive need to be inserted, too. I guess that's why the directive inserts here.