Hello, My research suggests my previous RFC patchs will not break any real-world programs (as far as I could find) and I will submit this patch set (previously, two RFC patch sets) for upstream contribution.
RFC PATCH 1 (combined to this): <https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629527.html> RFC PATCH 2 (combined to this): <https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629644.html> This patch set consists of two commits: 1. Changing signed types to unsigned types on bit manipulation and scalar crypto intrinsics. 2. Changing from uint64_t (changed from int64_t on the PATCH 1/2) to uint32_t on SHA-256, SM3 and SM4 intrinsics (all operate on 32-bit integers and upper 32-bits are not affected). This is in sync with following commits in LLVM (will be a part of 17): 1. 599421ae36c3 ("[RISCV] Use unsigned instead of signed types for Zk* and Zb* builtins.") 2. a64b3e92c7cb ("[RISCV] Re-define sha256, Zksed, and Zksh intrinsics to use i32 types.") Many RISC-V builtins operate in signed integer types but in many cases, they are better to be unsigned. It follows with a bit fixed cover letter from the previous RFC PATCH sets. Sincerely, Tsukasa Many RISC-V builtins operate in signed integer types but in many cases, they are better to be unsigned. There are a few reasons to do that in PATCH 1/2: 1. Being more natural For bit manipulation operations, the direct input and the manipulated result should have an unsigned type. e.g. __builtin_bswap16 Both input and output should be (and are) unsigned. e.g. __builtin_popcount The input should be (and is) unsigned. The output is a bit count and is in int (signed integer). 2. In parity with LLVM (likely in version 17) LLVM made similar changes to this patch set in the commit 599421ae36c3 ("[RISCV] Use unsigned instead of signed types for Zk* and Zb* builtins.") by Craig Topper. Note that shift amount / round number argument types are changed to unsigned in this LLVM commit, I did the same. 3. Minimum compatibility breakage This change rarely causes warnings even if both -Wall and -Wextra are specified. This is not completely compatible. For instance, we will notice when operating with for instance C++'s "auto" / "decltype" or overload resolution. But I consider this change in PATCH 1/2 is acceptable. There are also operations that only operate in 32-bit integers but require XLEN-bit wide integers. Intrinsics for SHA-256, SM3 and SM4 applies. PATCH 2/2 changes this in parity with the LLVM commit a64b3e92c7cb ("[RISCV] Re-define sha256, Zksed, and Zksh intrinsics to use i32 types.") by Craig Topper and makes those intrinsics accept/return uint32_t even on RV64. This instruction/expansion changes are based on the handling of 32-bit instructions on RV64 (such as ADDW). Before: riscv_<op>_si: For RV32, fully operate on uint32_t riscv_<op>_di: For RV64, fully operate on uint64_t After: *riscv_<op>_si: For RV32, fully operate on uint32_t riscv_<op>_di_extended: For RV64. Input is uint32_t and output is int64_t, sign-extended from the int32_t result (represents a part of <op> behavior). riscv_<op>_si: Common (fully operate on uint32_t). On RV32, "expands" to *riscv_<op>_si. On RV64, initially expands to riscv_<op>_di_extended and extracts lower 32-bits from the int64_t result. I think this (not completely compatible) change is still acceptable. Tsukasa OI (2): RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t gcc/config/riscv/crypto.md | 161 ++++++++++++------ gcc/config/riscv/riscv-builtins.cc | 14 +- gcc/config/riscv/riscv-cmo.def | 16 +- gcc/config/riscv/riscv-ftypes.def | 23 ++- gcc/config/riscv/riscv-scalar-crypto.def | 96 +++++------ gcc/testsuite/gcc.target/riscv/zbc32.c | 6 +- gcc/testsuite/gcc.target/riscv/zbc64.c | 6 +- gcc/testsuite/gcc.target/riscv/zbkb32.c | 10 +- gcc/testsuite/gcc.target/riscv/zbkb64.c | 8 +- gcc/testsuite/gcc.target/riscv/zbkc32.c | 4 +- gcc/testsuite/gcc.target/riscv/zbkc64.c | 4 +- gcc/testsuite/gcc.target/riscv/zbkx32.c | 4 +- gcc/testsuite/gcc.target/riscv/zbkx64.c | 4 +- gcc/testsuite/gcc.target/riscv/zknd32.c | 4 +- gcc/testsuite/gcc.target/riscv/zknd64.c | 10 +- gcc/testsuite/gcc.target/riscv/zkne32.c | 4 +- gcc/testsuite/gcc.target/riscv/zkne64.c | 8 +- .../gcc.target/riscv/zknh-sha256-32.c | 10 ++ .../riscv/{zknh-sha256.c => zknh-sha256-64.c} | 8 +- .../gcc.target/riscv/zknh-sha512-32.c | 12 +- .../gcc.target/riscv/zknh-sha512-64.c | 8 +- gcc/testsuite/gcc.target/riscv/zksed32.c | 4 +- gcc/testsuite/gcc.target/riscv/zksed64.c | 4 +- gcc/testsuite/gcc.target/riscv/zksh32.c | 4 +- gcc/testsuite/gcc.target/riscv/zksh64.c | 4 +- 25 files changed, 247 insertions(+), 189 deletions(-) create mode 100644 gcc/testsuite/gcc.target/riscv/zknh-sha256-32.c rename gcc/testsuite/gcc.target/riscv/{zknh-sha256.c => zknh-sha256-64.c} (79%) base-commit: fb4b53d964b797e5f3380726175c95110c4ff9ff -- 2.42.0
