Re: [PATCH v2 00/15] RISC-V: Add Zbb-optimized string routines as ifuncs

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 27/05/24 08:18, Christoph Müllner wrote:
> Glibc recently got hwprobe() support for RISC-V, which allows querying
> avaiable extensions at runtime.  On top of that an optimized memcpy()
> routine (for fast unaligned accesses) has been merged, which is built by
> recompiling the generic C code with a different compiler flag.  An ifunc
> resolver then detects which routine should be run using hwprobe().
> 
> This patchset follows this idea and recompiles the following functions
> for Zbb (via function attributes) and enables the existing Zbb/orc.b
> optimization in riscv/string-fza.h:
> memchr, memrchr, strchrnul, strcmp, strlen, strncmp.
> The resulting optimized routines are then selected by the resolver function
> if the Zbb extension is present at runtime.
> 
> To use target function attributes, a few issues had to be resovled:
> - The functions above got a mechanism to be compiled with function attributes
>   (patches 2-7).  Only those routines have been touched, which are
>   required for the purpose of this patchset.
> - Ensuring that inlined functions also get the same function attributes
>   (first patch).
> - Add mechanism to explicitly enable the orc.b optimization for string functions
>   (patch 8), which is a bit inspired by USE_FFS_BUILTIN.
> 
> One of the design questions is, if Zbb represents a broad enough optimization
> target.  Tests with Zb* extensions showed, that no further code improvements
> can be achieved with them.  Also most other extensions likely won't affect
> the generated code for string routines (ignoring vector instructions, which
> are a different topic).  Therefore, Zbb seemed like a sufficient target.
> 
> This series was tested by writing a simple test program to invoke the
> libc routines (e.g. strcmp) and a modified QEMU that reports the
> emulation of orc.b on stderr.  With that the QEMU can be used to test
> if the optimized routines are executed (-cpu "rv64,zbb=[false,true]").
> Further, this series was tested with SPEC CPU 2017 intrate with Zbb
> enabled.  The function attribute detection mechanism was tested with
> GCC 13 and GCC 14.
> 

I tried check this patchset with gcc 14 [1] (commit 6f6103ccc5b3bf8cb,
built with build-many-glibcs.py) and it shows an ICE:

$ riscv64-glibc-linux-gnu-gcc ../sysdeps/riscv/multiarch/memchr-zbb.c [...]
In file included from ../include/bits/string_fortified.h:1,
                 from ../string/string.h:548,
                 from ../include/string.h:60,
                 from ../string/memchr.c:24,
                 from ../sysdeps/riscv/multiarch/memchr-zbb.c:23:
../string/bits/string_fortified.h:110:1: internal compiler error: in riscv_func_target_put, at common/config/riscv/riscv-common.cc:510
  110 | {
      | ^
0x7af52762a1c9 __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x7af52762a28a __libc_start_main_impl
        ../csu/libc-start.c:360

I am building with --enable-fortify-source=2, with --enable-fortify-source=no
the build does not fail. A gcc 13 build [2] seems to be in better shape but 
the version I am using does not have support for required attributes 
(HAVE_RISCV_FATTRIBUTE_ZBB is set to 0).

So I think we will need to check whether this is still happens with
gcc master/15 and see if indeed it was a regression added on gcc 14.

[1] gcc version 14.1.1 20240619 [releases/gcc-14 r14-10324-g6f6103ccc5b]
[2] gcc version 13.1.1 20230525 [releases/gcc-13 r13-7376-ge80487dcbe2]