These patches support RISCV ISA float16. ref: https://github.com/riscv/riscv-isa-manual/blob/main/src/zfh.adoc
Created attachment 181637 [details] 0001-riscv64-Add-zfh-extension-support-VEX-modifications.patch
Created attachment 181638 [details] 0002-riscv64-Add-zfh-extension-support-test-modifications.patch
Created attachment 181639 [details] 0003-riscv64-Add-zfh-extension-support-new-port-specific-.patch
Created attachment 181640 [details] 0004-riscv64-Add-zfh-extension-support-new-port-specific-.patch
We probably need a real implementation of riscv_hwprobe see https://bugs.kde.org/show_bug.cgi?id=503253 Are there other ways programs check the availability of riscv extensions? Are there auxval settings for example? Or do programs probe by just trying to execute some extension instruction?
(In reply to Mark Wielaard from comment #5) > We probably need a real implementation of riscv_hwprobe see > https://bugs.kde.org/show_bug.cgi?id=503253 > Are there other ways programs check the availability of riscv extensions? > Are there auxval settings for example? > Or do programs probe by just trying to execute some extension instruction? This patch need to compile Valgrind with compiler's option "-march=xxx_zfh" to enable Zfh extension by now, it does not smart to detect host CPU ISA features dynamically :)
Created attachment 182112 [details] 0005-riscv64-Add-zfh-extension-support-determine-hardware.patch
(In reply to Mark Wielaard from comment #5) > We probably need a real implementation of riscv_hwprobe see > https://bugs.kde.org/show_bug.cgi?id=503253 > Are there other ways programs check the availability of riscv extensions? > Are there auxval settings for example? > Or do programs probe by just trying to execute some extension instruction? I make a patch for determining hardware capability by trying to execute extension instruction. Please review these :)
(In reply to JojoR from comment #8) > (In reply to Mark Wielaard from comment #5) > > We probably need a real implementation of riscv_hwprobe see > > https://bugs.kde.org/show_bug.cgi?id=503253 > > Are there other ways programs check the availability of riscv extensions? > > Are there auxval settings for example? > > Or do programs probe by just trying to execute some extension instruction? > > I make a patch for determining hardware capability > by trying to execute extension instruction. > > Please review these :) [PATCH 5/5] riscv64: Add zfh extension support: determine hardware capability Looks good. So now valgrind can detect if the hardware supports and we need to change the #ifdef __riscv_zfh checks in libvex with checks against having VEX_HWCAPS_RISCV_Zfh in hwcaps. Then if a program uses the same kind of illegal instruction check this should work. But if the program uses the riscv_hwprobe syscall it won't. So we still need an implementation of https://bugs.kde.org/show_bug.cgi?id=503253 For the testcases you will have to add something like ./tests/x86_amd64_features.c so you can add it to the vgtests as e.g. prereq: test -x float16 && ../../../tests/riscv64_features riscv64-Zfh And you should really check for __riscv_zfh in a configure check, so that you only build the tests if the compiler knows about it.
Created attachment 182851 [details] 0004-riscv64-Add-zfh-extension-support-new-port-specific-.patch
Created attachment 182852 [details] 0005-riscv64-Add-zfh-extension-support-determine-hardware.patch
(In reply to Mark Wielaard from comment #9) > (In reply to JojoR from comment #8) > > (In reply to Mark Wielaard from comment #5) > > > We probably need a real implementation of riscv_hwprobe see > > > https://bugs.kde.org/show_bug.cgi?id=503253 > > > Are there other ways programs check the availability of riscv extensions? > > > Are there auxval settings for example? > > > Or do programs probe by just trying to execute some extension instruction? > > > > I make a patch for determining hardware capability > > by trying to execute extension instruction. > > > > Please review these :) > > [PATCH 5/5] riscv64: Add zfh extension support: determine hardware > capability > > Looks good. So now valgrind can detect if the hardware supports and we need > to change the #ifdef __riscv_zfh checks in libvex with checks against having > VEX_HWCAPS_RISCV_Zfh in hwcaps. > Updated patch "0005-riscv64-Add-zfh-extension-support-determine-hardware.patch" I will check Zfh feature before calling disassembler function "dis_RV64Zfh" > Then if a program uses the same kind of illegal instruction check this > should work. But if the program uses the riscv_hwprobe syscall it won't. So > we still need an implementation of > https://bugs.kde.org/show_bug.cgi?id=503253 > It looks like an independent feature ? I will see that later. > For the testcases you will have to add something like > ./tests/x86_amd64_features.c so you can add it to the vgtests as e.g. > prereq: test -x float16 && ../../../tests/riscv64_features riscv64-Zfh > > And you should really check for __riscv_zfh in a configure check, so that > you only build the tests if the compiler knows about it. Updated patch "0004-riscv64-Add-zfh-extension-support-new-port-specific-.patch" Like other arch, I add "prereq" condition in execution for Zfh feature.
@Mark Any other suggestions for these patches ?
Any maintainer help to review or submit RISCV patches ?
hello ?
(In reply to JojoR from comment #15) > hello ? Hi! Sorry, I didn't forget. But I just ran out of time for the v3.26.0 release.