mbox series

[RFC,0/2] RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types

Message ID cover.1694053004.git.research_trasio@irq.a4lg.com
Headers
Series RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types |

Message

Tsukasa OI Sept. 7, 2023, 2:17 a.m. UTC 
  Hello,

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:

1.  Being more natural
    For bit manipulation operations, the direct input and the 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 17
    LLVM made similar changes to this patch set in 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.  In fact, only applying PATCH 1/2 does not cause any
    additional test failures.  PATCH 2/2 only contains testsuite changes
    (uses correct types as the builtin uses).

But not completely compatible.  For instance, we will notice when operating
with for instance C++'s "auto" / "decltype" or overload resolution.

So, I would like to hear your thoughts first.

Note that, the only reason I separated this RFC patch set to two patches
is to demonstrate that no additional warnings occur even if only PATCH 1/2
is applied.  If approved or leaves an RFC PATCH, both will be merged.


p.s.

LLVM has another type of different builtin types (with the same name),
scalar cryptography builtins that operate in 32-bit integers, not XLEN-
specific (applies to SHA-256, SM3 and SM4).  For those cases, GCC prefers
XLEN-specific integer type but LLVM 17 always prefers uint32_t.

This is a result of LLVM commit 599421ae36c3 ("[RISCV] Re-define sha256,
Zksed, and Zksh intrinsics to use i32 types.").

Because just changing the width causes errors on GCC, even if I change them
to uint32_t, that would be in a different patch set.


Sincerely,
Tsukasa




Tsukasa OI (2):
  RISC-V: Make bit manipulation value / round number and shift amount
    types for builtins unsigned
  RISC-V: Update testsuite for type-changed builtins

 gcc/config/riscv/riscv-builtins.cc            |   7 +-
 gcc/config/riscv/riscv-cmo.def                |  16 +--
 gcc/config/riscv/riscv-ftypes.def             |  24 ++--
 gcc/config/riscv/riscv-scalar-crypto.def      | 104 +++++++++---------
 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/testsuite/gcc.target/riscv/zknh-sha256.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 +-
 23 files changed, 133 insertions(+), 134 deletions(-)


base-commit: af88776caa20342482b11ccb580742a46c621250