ack, just back from summit China, and this patch definlty is what I will review, put in my work queue now :)
Jeff Law <[email protected]> 於 2026年10月23日週五 下午12:08寫道： > > > > On 10/21/26 6:23 AM, Eldar Osmanovic wrote: > > From: Djordje Todorovic <[email protected]> > > > > The RISC-V psABI requires named 2 * XLEN scalar arguments and > > return values to use significance-based register-pair ordering: > > the lower-order XLEN bits are passed in the lower-numbered register, > > and the higher-order XLEN bits are passed in the higher-numbered > > register. This ordering is independent of endianness and applies > > to both RV32 and RV64. > > > > On big-endian targets, significance ordering differs from memory-layout > > ordering. If exactly one argument register is available, the low-order > > XLEN bits are passed in the register and the high-order XLEN bits are > > passed on the stack. > > > > Keep anonymous variadic arguments and aggregates on the existing > > memory-layout ordering path, so va_arg spill layout remains > > correct on big-endian targets. Floating-point reals also remain on the > > memory-layout ordering path according to the psABI. > > > > The relevant big-endian calling-convention rules were introduced by the > > RISC-V ELF psABI change recently [1]. > > > > [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/470 > > > > Co-authored-by: Eldar Osmanovic <[email protected]> > > Signed-off-by: Djordje Todorovic <[email protected]> > > Signed-off-by: Eldar Osmanovic <[email protected]> > > > > gcc/ChangeLog: > > > > * config/riscv/riscv.cc (riscv_2xlen_significance_scalar_p): > > New function. > > (riscv_pass_2xlen_scalar_gpr_pair): Likewise. > > (riscv_pass_2xlen_scalar_gpr_stack): Likewise. > > (riscv_get_arg_info): Use significance-based ordering for named > > 2 * XLEN scalar arguments and return values. > > (riscv_function_arg_1): New common implementation. Handle > > 2 * XLEN scalar split between a GPR and the stack. > > (riscv_function_arg): Use riscv_function_arg_1. > > (riscv_function_incoming_arg): New function. > > (TARGET_FUNCTION_INCOMING_ARG): Define. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/riscv/abi/rv32be-abi-2xlen-aggregate-return.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-aggregate-split.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-aggregate.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-float-incoming.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-ilp32e-scalar.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-scalar-arg.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-scalar-incoming.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-scalar-return.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-scalar-sibcall.c: New test. > > * gcc.target/riscv/abi/rv32be-abi-2xlen-scalar-split.c: New test. > > * gcc.target/riscv/abi/rv64be-abi-2xlen-scalar-incoming.c: New test. > > * gcc.target/riscv/abi/rv64be-abi-2xlen-vararg.c: New test. > > --- > My recollection is that a PARALLEL for a return value means we're > returning the value in two locations. Though I guess after re-reading > the documentation in this space you could possibly model what you need > via the PARALLEL mechanism -- rather than N*2 entries in the PARALLEL > for the different locations, you just have one entry pair describing > each word sized component. > > I'd like Kito to take a look at the patch since he's been involved in > the ABI discussion. > > I would also suggest looking at the Sashiko output. I haven't thought > hard about the issues it raised, so review it with a skeptical eye. > > https://gcc.sashiko.dev/#/patchset/20261021122253.62110-1-eldar.osmanovic%40htecgroup.com > > Jeff
