On Wed, Jul 17, 2024 at 1:14 AM Palmer Dabbelt <pal...@dabbelt.com> wrote: > > On Tue, 16 Jul 2024 07:49:13 PDT (-0700), kito.ch...@sifive.com wrote: > > This provides a common abstraction layer to probe the available extensions > > at > > run-time. These functions can be used to implement function > > multi-versioning or > > to detect available extensions. > > > > The advantages of providing this abstraction layer are: > > - Easy to port to other new platforms. > > - Easier to maintain in GCC for function multi-versioning. > > - For example, maintaining platform-dependent code in C code/libgcc is > > much > > easier than maintaining it in GCC by creating GIMPLEs... > > > > This API is intended to provide the capability to query minimal common > > available extensions on the system. > > > > Proposal in riscv-c-api-doc: > > https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74 > > > > Full function multi-versioning implementation will come later. We are > > posting > > this first because we intend to backport it to the GCC 14 branch to unblock > > LLVM 19 to use this with GCC 14.2, rather than waiting for GCC 15. > > Is LLVM actually going to use this? Last I heard the plan was to just > wait until we're much closer to the glibc release so the hwprobe() libc > ABI is frozen and then just call that directly.
Yes, current LLVM implementation(PR, not merged yet) still use that, the guy who implement the LLVM part is our LLVM folk in Taiwan and he would prefer this libgcc/compiler-rt over call hwprobe (either call by ifunc resolver's function parameter or syscall directly), one another point is we feel that's kinda layering violation if we implement that in compiler (which without libgcc/compiler-rt), also again, it's not easy to maintain and implement in either LLVM IR or GCC GIMPLE.
