The StarFive JH7110's U74 cores implement rv64imafdc_..._zba_zbb, so the U74
target now compiles with -march=rv64imafdc_zba_zbb. The generic RISCV64_GENERIC
target stays at bare rv64imafdc for portability across unknown RV64GC cores.
Measured on the VisionFive 2 (GCC 13.3, -mtune=sifive-u74 held constant): GCC
emits Zba shift-add instructions in the packing routines, but DGEMM is unchanged
-- the 4x4 kernel holds 1.533 GF either way and packing 1.74 vs 1.75 GB/s. The
4x4 micro-kernel is FMA-bound (fused fmadd.d with immediate-offset loads) and
packing is LPDDR4-bandwidth-bound, so integer address generation is not on the
critical path. The flag is nonetheless the correct -march for the silicon, is
free, and can only help address-gen-bound code elsewhere in the library. The
remaining GEMM headroom on the U74 is microarchitectural scheduling (a
hand-written assembly micro-kernel), not the ISA.
The SiFive U74 (RV64GC; e.g. StarFive JH7110 / VisionFive 2) is a scalar,
in-order core with no RVV, so today it falls back to RISCV64_GENERIC whose
S/D GEMM uses the generic 2x2 C micro-kernel.
Per the U74 Core Complex Manual (Table 169) fmadd.d has a 7-cycle latency
at repeat rate 1 (fully pipelined). A 2x2 tile exposes only 4 independent
accumulator chains -- fewer than the FMA latency -- so the FP pipe stalls
on the accumulator dependency, and the 1:1 load:FMA ratio saturates the
single load/store pipe ("only one outstanding line fill", manual 8.2).
This adds a portable 4x4 GEMM micro-kernel and a dedicated U74 target:
- kernel/generic/gemmkernel_4x4.c: 16-accumulator 4x4 register tile. 16
independent chains exceed the 7-cycle latency, and the load:FMA ratio
drops to 1:2. 16 acc + 4 A + 4 B fit RV64G's 32 FP registers without
spilling. Full 4/2/1 edge handling in both M and N.
- U74 target wiring: getarch.c (FORCE_U74, 32 KiB/64 B L1D, 2 MiB L2),
param.h (S/D UNROLL 4/4; complex stays 2/2), kernel/riscv64/KERNEL.U74
(S/D GEMM -> gemmkernel_4x4 + gemm_[nt]copy_4; S/D TRMM -> existing
trmmkernel_4x4), Makefile.prebuild + Makefile.riscv64 (-mtune=sifive-u74),
TargetList.txt, cpuid_riscv64.c.
The 4x4 kernel was verified numerically against a naive reference GEMM,
driven through the real gemm_tcopy_4 / gemm_ncopy_4 packing routines,
across 27,436 M/N/K x alpha combinations covering every 4/2/1 tail case:
worst absolute error 0.
Build with: make TARGET=U74
The compiler options that enable 16 bit floating point instructions
should not be enabled by default when building the RISCV64_ZVL128B
and RISCV64_ZVL256B targets. The zfh and zvfh extensions are not part
of the 'V' extension and are not required by any of the RVA profiles.
There's no guarantee that kernels built with zfh and zvfh will work
correctly on fully compliant RVA23U64 devices.
To fix the issue we only build the RISCV64_ZVL128B and RISCV64_ZVL256B
kernels with the half float flags if BUILD_HFLOAT16=1. We also update
the RISC-V dynamic detection code to disable the RISCV64_ZVL128B and
RISCV64_ZVL256B kernels at runtime if we've built with DYNAMIC_ARCH=1
and BUILD_HFLOAT16=1 and are running on a device that does not support
both Zfh and Zvfh.
Fixes: https://github.com/OpenMathLib/OpenBLAS/issues/5428
Added HFLOAT16 support for RISCV64
Added shgemm_kernel_8x8 for RISCV64_ZVL128B and shgemm_kernel_16x8 for RISCV64_ZVL256B based on HFLOAT16
The instruction sets used are ZVFH and ZFH, which need to be supported by RVV1.0
Related to issue #5279
Co-authored-by Linjin Li <linjin_li@163.com>
* Fixed bugs in dgemm, [a]min\max, asum kernels
* Added zero checks for BLAS kernels
* Added dsdot implementation for RVV 0.7.1
* Fixed bugs in _vector files for C910V and RISCV64_ZVL256B targets
* Added additional definitions for RISCV64_ZVL256B target
Current RVV x280 target depends on vlen=512-bits for Level 3 operations.
Commit adds generic target that supports vlen=128-bits.
New target uses the same scalable kernels as x280 for Level 1&2 operations, and autogenerated kernels for Level 3 operations.
Functional correctness of Level 3 operations tested on vlen=128-bits using QEMU v8.1.1 for ctests and BLAS-Tester.
- config.h was used as target even when it wasn't generated.
This only worked because the 'dummy' target always triggers
a full rebuild.
It is however better to specify the exact target that is to
be rebuilt do avoid confusion.
- Explicitly mark 'dummy' as a 'phony' target.
Signed-off-by: Egbert Eich <eich@suse.com>
Hard-coding gcc may not provide incorrect results when a different compiler
for the target build is used. To remain in sync with the main call to c_check,
pass the full command line.
Signed-off-by: Egbert Eich <eich@suse.com>
hmeiland