Add a conservative RISC-V build path for TensorFlow Lite dependencies

[carlosqwqqwq]

Why

Larq Compute Engine already has portable bitpacking, BGEMM, and indirect-BGEMM paths for non-AArch64 targets, but its bundled TensorFlow Lite dependency chain is not conservative enough for a riscv64 Linux target that lacks sys/hwprobe.h.

In a fresh dockcross/linux-riscv64 cross-build, third-party cpuinfo still tried to compile its RISC-V Linux hwprobe source and failed before the portable kernels could be used. The goal of this patch is not to disable acceleration for all RISC-V systems, but to provide a conservative fallback only when that target header is unavailable while preserving the upstream accelerated path on RISC-V systems that do provide it.

What changed

• Updated CMakeLists.txt so riscv* Linux targets first probe for sys/hwprobe.h.
• Only when that header is unavailable, disable TFLITE_ENABLE_XNNPACK and expose a small cmake/riscv_cpuinfo_shim/ library as cpuinfo::cpuinfo.
• The shim intentionally returns cpuinfo_initialize() == false, which lets TensorFlow Lite's bundled ruy fall back to its existing fixed-cache conservative path instead of depending on Linux hwprobe headers.
• If sys/hwprobe.h is available, the upstream cpuinfo / XNNPACK path is left unchanged.
• Kept the change scoped to build-system plumbing only. This patch does not claim RVV support, custom RISC-V intrinsics, or any new assembly backend.

Verification

• Real riscv64 cross-build completed successfully in dockcross/linux-riscv64 with:
  • cmake -S /work -B /tmp/build -G Ninja -DCOMPILE_BENCHMARK=OFF
  • cmake --build /tmp/build --parallel 4
• CMakeCache.txt from that real build records:
  • TFLITE_ENABLE_XNNPACK:BOOL=OFF
  • RUY_FIND_CPUINFO:BOOL=OFF
• build.ninja shows:
  • cmake/riscv_cpuinfo_shim/cpuinfo.c compiled into libcpuinfo.a
  • no src/riscv/linux/riscv-hw.c
  • TensorFlow Lite objects built with -DTFLITE_WITHOUT_XNNPACK
• file and readelf -h confirm the produced example binary is a real RISC-V ELF executable.
• qemu-riscv64 -L ... -E LD_LIBRARY_PATH=/lib:/usr/lib ./example starts successfully and prints:
  • lce_minimal <tflite model>
• A lightweight CMake probe confirmed the new condition behaves as intended:
  • without sys/hwprobe.h, the RISC-V fallback path is selected;
  • with a provided sys/hwprobe.h, the fallback path is not selected.

Notes

• This patch is intentionally conservative. It keeps RISC-V on the existing portable kernels only when the bundled dependency chain cannot build its RISC-V Linux hwprobe support.
• The cpuinfo shim is only used on riscv* Linux targets that do not provide sys/hwprobe.h, and its behavior is deliberately minimal: fail feature detection cleanly so bundled ruy can use its already-existing fallback path.
• I am still treating this as a basic portability patch, not as a performance-optimized RISC-V backend.

[Tombana]

Thank you for contributing!

If I understand correctly, a riscv64 build fails because the dependency cpuinfo depends on sys/hwprobe.h which is not available. This PR disables XNNPACK and fakes cpuinfo so that sys/hwprobe.h is not needed, and by returning false it will make tflite (at runtime) fall back to generic kernels.

The XNNPACK readme (https://github.com/google/XNNPACK) lists support for 'RISC-V (RV32GC and RV64GC)'.
Does that mean that on some other risc-v systems, sys/hwprobe.h is available ? In that case your PR would disable XNNPACK acceleration for those systems right? Would it be possible to change the condition CMAKE_SYSTEM_PROCESSOR MATCHES "^riscv" to something else, so that on your risc-v system your changes apply, but other risc-v systems that have support for cpuinfo can still use the optimized kernels?

Perhaps I'm misunderstanding something here, so let me know if what I said is not correct.

[carlosqwqqwq]

Thanks, that is a fair concern. My previous change was too broad and would have disabled the accelerated path for all riscv* targets. I have narrowed it so the fallback only applies on RISC-V Linux targets that do not provide sys/hwprobe.h. If that header is available, the upstream cpuinfo / XNNPACK path is left unchanged.

[carlosqwqqwq]

Thanks for the detailed feedback. I pushed an update in 1db473b.

The condition is now narrower:

• only riscv* + Linux
• and only when sys/hwprobe.h is not available

If sys/hwprobe.h is present, the upstream cpuinfo / XNNPACK path is left unchanged.
If it is missing, the build falls back to the conservative non-XNNPACK path so the portable kernels can still be used instead of failing during configuration.

I also re-checked both branches of the condition locally:

• without sys/hwprobe.h, the fallback path is selected;
• with sys/hwprobe.h available, the fallback path is not selected.

[Tombana]

Two suggestions to simplify things, and can you revert the changes to README.md ?

[carlosqwqqwq]

Thanks for the suggestions. I pushed a follow-up in 7c6673f: the README.md changes are reverted, and the patch is narrowed further so it only keeps the build-side fallback for RISC-V Linux targets without sys/hwprobe.h.

Please take another look when you have time.