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

[Christoph Müllner]

On Wed, Jun 19, 2024 at 4:26 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> 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.

I can reproduce the issue with gcc 14 and master/15.

While analysing this, I've discovered two issues in GCC
when processing target-arch attributes:
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115554
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115562

Both issues trigger an ICE because of a violated assertion in
riscv_func_target_put().
While the first issue could be fixed by replacing the assertion with
an error message,
the second requires more work. Unfortunately, it is the second issue
that is causing
this patchset to not build.

GCC 13 or earlier are not affected, because the RISC-V backend did not support
target-arch attributes back then.

Thanks,
Christoph

> [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]