On 11/15/24 8:21 PM, Liao Shihua wrote:
RISC-V N32 ABI means using 32-bit ABI on 64-bit ISA, the discussion in
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/381 .
At this moment, N32 is supported batemental toolchain.
Three OpenSource RTOS using this feature and have been merged in upstream.
You can see them in
EasyXem (AUTOSAR CP R19-11):
https://atomgit.com/easyxmen/XMen/tree/rv64ilp32-dev
Nuttx: https://github.com/apache/nuttx
RT-Thread:https://github.com/RT-Thread/rt-thread/pull/9194
This patch support N32(32-bit ABI on 64-bit ISA) in riscv
It remove option check when -march=rv64* -mabi=ilp32. And replace XLEN_SPEC in
LINK_SPEC by ABI_LEN_SPEC. In addition, it some machine descriptions.
gcc/ChangeLog:
* config.gcc:Allow rv64* ISA use ilp32 ABI
* config/riscv/bitmanip.md: change some machine descriptions.
* config/riscv/elf.h (LINK_SPEC): Enable elf32 on rv64 ISA
* config/riscv/riscv.cc (riscv_option_override): remove check ilp32 on
rv64.
* config/riscv/riscv.h (TARGET_ILP32): Add TARGET_ILP32 like
TARGET_64BIT.
(POINTER_SIZE): Change POINTER_SIZE belong to ABI.
(Pmode): Likewise.
(ABI_LEN_SPEC): Likewise
* config/riscv/riscv.md: Change some machine descriptions.
---
gcc/config.gcc | 3 +++
gcc/config/riscv/bitmanip.md | 4 ++--
gcc/config/riscv/elf.h | 2 +-
gcc/config/riscv/riscv.cc | 3 ++-
gcc/config/riscv/riscv.h | 10 +++++++++-
gcc/config/riscv/riscv.md | 20 ++++++++++++--------
6 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 9b616bd6e1f..a1b737117a0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4828,6 +4828,9 @@ case "${target}" in
ilp32,rv32* | ilp32e,rv32e* \
| ilp32f,rv32*f* | ilp32f,rv32g* \
| ilp32d,rv32*d* | ilp32d,rv32g* \
+ | ilp32,rv64* | ilp32e,rv64e* \
+ | ilp32f,rv64*f* | ilp32f,rv64g* \
+ | ilp32d,rv64*d* | ilp32d,rv64g* \
| lp64,rv64* | lp64e,rv64e* \
| lp64f,rv64*f* | lp64f,rv64g* \
| lp64d,rv64*d* | lp64d,rv64g*)
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 06ff698bfe7..4002f05acb8 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -351,7 +351,7 @@
{
if (TARGET_XTHEADBB && !immediate_operand (operands[2], VOIDmode))
FAIL;
- if (TARGET_64BIT && register_operand (operands[2], QImode))
+ if (TARGET_64BIT && !TARGET_ILP32 && register_operand (operands[2], QImode))
{
rtx t = gen_reg_rtx (DImode);
emit_insn (gen_rotrsi3_sext (t, operands[1], operands[2]));
@@ -393,7 +393,7 @@
(match_operand:QI 2 "register_operand" "r")))]
"TARGET_ZBB || TARGET_ZBKB"
{
- if (TARGET_64BIT)
+ if (TARGET_64BIT && !TARGET_ILP32)
{
rtx t = gen_reg_rtx (DImode);
emit_insn (gen_rotlsi3_sext (t, operands[1], operands[2]));
So circiling back from the pathwork meeting, I'd like to understand why
these changes were made (and similar ones in riscv.md).
I don't immediately see how they'd be a correctness issue for ILP32, but
I could perhaps see how they might interact with pointer masking. I
could also see them as a performance question/concern in the ILP32 space.
So the ask is for you to provide more details about why these changes
were made -- what specific problem is being solved?
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 7694954c4c5..0390bece98b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -10471,7 +10471,8 @@ riscv_option_override (void)
error ("z*inx requires ABI ilp32, ilp32e, lp64 or lp64e");
/* We do not yet support ILP32 on RV64. */
- if (BITS_PER_WORD != POINTER_SIZE)
+ if (BITS_PER_WORD != POINTER_SIZE
+ && !(BITS_PER_WORD == 64 && POINTER_SIZE == 32))
error ("ABI requires %<-march=rv%d%>", POINTER_SIZE);
Note that I think we'll need to adjust the comment since once this work
is completed & integrated we'll be supporting ILP32 on RV64 :-)
@@ -3818,6 +3818,10 @@
"reload_completed"
[(const_int 0)]
{
+ if (GET_MODE (operands[0]) != Pmode)
+ operands[0] = convert_to_mode (Pmode, operands[0], 0);
+ if (GET_MODE (operands[1]) != Pmode)
+ operands[1] = convert_to_mode (Pmode, operands[1], 0);
riscv_set_return_address (operands[0], operands[1]);
DONE;
})
I'd think we could change the mode of operands 0 and 1 in the pattern.
That seems like a better way to fix this problem. Is there a reason why
that wouldn't work? I'd think we could use :P for both operands to
ensure a Pmode operand.
Jeff
