diff options
author | Jeff Law <jlaw@ventanamicro.com> | 2024-05-07 11:43:09 -0600 |
---|---|---|
committer | Jeff Law <jlaw@ventanamicro.com> | 2024-05-07 11:43:09 -0600 |
commit | 1139f38e798181572121657e5b267a9698edb62f (patch) | |
tree | 64c02b5b02ffb797dc09fde69f18cdfd3307c8a9 /gcc/config/riscv/riscv-string.cc | |
parent | d6d7afcdbc04adb0ec42a44b2d7e05600945af42 (diff) | |
download | gcc-1139f38e798181572121657e5b267a9698edb62f.zip gcc-1139f38e798181572121657e5b267a9698edb62f.tar.gz gcc-1139f38e798181572121657e5b267a9698edb62f.tar.bz2 |
[RISC-V] [PATCH v2] Enable inlining str* by default
So with Chrstoph's patches from late 2022 we've had the ability to inline
strlen, and str[n]cmp (scalar). However, we never actually turned this
capability on by default!
This patch flips the those default to allow inlinining by default. It also
fixes one bug exposed by our internal testing when NBYTES is zero for strncmp.
I don't think that case happens enough to try and optimize it, we just disable
inline expansion for that instance.
This has been bootstrapped and regression tested on rv64gc at various times as
well as cross tested on rv64gc more times than I can probably count (we've have
this patch internally for a while). More importantly, I just successfully
tested it on rv64gc and rv32gcv elf configurations with the trunk
gcc/
* config/riscv/riscv-string.cc (riscv_expand_strcmp): Do not inline
strncmp with zero size.
(emit_strcmp_scalar_compare_subword): Adjust rotation for rv32 vs rv64.
* config/riscv/riscv.opt (var_inline_strcmp): Enable by default.
(vriscv_inline_strncmp, riscv_inline_strlen): Likewise.
gcc/testsuite
* gcc.target/riscv/zbb-strlen-disabled-2.c: Turn off inlining.
Diffstat (limited to 'gcc/config/riscv/riscv-string.cc')
-rw-r--r-- | gcc/config/riscv/riscv-string.cc | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc index b09b51d..41cb061 100644 --- a/gcc/config/riscv/riscv-string.cc +++ b/gcc/config/riscv/riscv-string.cc @@ -153,7 +153,7 @@ emit_strcmp_scalar_compare_subword (rtx data1, rtx data2, rtx orc1, rtx imask = gen_rtx_CONST_INT (Xmode, im); rtx m_reg = gen_reg_rtx (Xmode); emit_insn (gen_rtx_SET (m_reg, imask)); - do_rotr3 (m_reg, m_reg, GEN_INT (64 - cmp_bytes * BITS_PER_UNIT)); + do_rotr3 (m_reg, m_reg, GEN_INT (BITS_PER_WORD - cmp_bytes * BITS_PER_UNIT)); do_and3 (data1, m_reg, data1); do_and3 (data2, m_reg, data2); if (TARGET_ZBB) @@ -497,6 +497,13 @@ riscv_expand_strcmp (rtx result, rtx src1, rtx src2, return false; nbytes = UINTVAL (bytes_rtx); + /* If NBYTES is zero the result of strncmp will always be zero, + but that would require special casing in the caller. So for + now just don't do an inline expansion. This probably rarely + happens in practice, but it is tested by the testsuite. */ + if (nbytes == 0) + return false; + /* We don't emit parts of a strncmp() call. */ if (nbytes > compare_max) return false; |