Skip to content

add support for loongarch64 - #1254

Open
mogoweb wants to merge 2 commits into
lightvector:masterfrom
mogoweb:develop/loong64
Open

mogoweb wants to merge 2 commits into
lightvector:masterfrom
mogoweb:develop/loong64

Conversation

@mogoweb

@mogoweb mogoweb commented Sep 14, 2026

Copy link
Copy Markdown

Support non-x86 builds, and let the NN tests run on the Eigen backend

Two independent fixes found while building KataGo on loongarch64 with the Eigen backend.
Each is in its own commit. Neither changes behavior on any currently supported platform.

1. Only pass -mfpmath=sse on x86

The GNU/Clang branch of the build setup treated "not ARM" as "is x86":

if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "(arm|aarch32|aarch64)")
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsigned-char")
else()
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mfpmath=sse")

-mfpmath=sse only exists on x86. On loongarch64 (and riscv64, ppc64le, mips64, ...) every
translation unit fails immediately:

c++: error: unrecognized command-line option '-mfpmath=sse'

so the build dies at ~2% with no usable binary. The else() is now an explicit x86 match.

This is safe rather than merely cosmetic: the comment already notes that SSE-based IEEE float
math is the ABI default on x86-64 and that x87 excess precision cannot occur, so the flag is a
no-op there. Nothing loses IEEE compliance by restricting it to x86 — the goal was just to state
the requirement explicitly.

2. Normalize NHWC and FP16 test args for the Eigen backend

The Eigen backend only implements the NHWC float32 path and hard-errors otherwise:

  • eigenbackend.cpp:2425inputsUseNHWC = false unsupported
  • eigenbackend.cpp:2663 (and siblings) — useFP16 = true not supported

But the test scripts pass exactly those. runsearchtestslimited.sh and runsearchtests.sh were
written for OpenCL, so they invoke e.g. runsearchtests <model> false false 0 false (NCHW) and
runsearchtestsv8 <model> true true true (FP16). Every NN test therefore aborted with SIGABRT
before doing any work.

TestCommon::overrideForBackends() exists for precisely this kind of normalization, but it only
knows OpenCL and TensorRT, and testsearchmisc.cpp's runNNSymmetriesTest / runNNBatchingTest
never call it at all. Rather than extend that function (it takes only two params, so it cannot see
useFP16) and fix up ~13 call sites, the clamp goes in the two startNNEval helpers:

  • cpp/tests/testsearchcommon.cpp
  • cpp/tests/testtrainingwrite.cpp (its own file-local startNNEval)

Those are the single choke point every NN test goes through, so this also covers the two
testsearchmisc.cpp cases that never reached overrideForBackends. Guarded by
#if defined(USE_EIGEN_BACKEND), so OpenCL / CUDA / TensorRT / ROCm / Metal / ONNX builds are
bit-for-bit unaffected.

chenzhengyong added 2 commits September 14, 2026 21:12
The GNU/Clang branch treated "not ARM" as "is x86", so every non-x86 ISA
(loongarch64, riscv64, ppc64le, mips64, ...) was handed -mfpmath=sse and
failed to compile any translation unit with "unrecognized command-line
option '-mfpmath=sse'".

The flag is already a no-op on x86-64 - SSE-based IEEE float math is the
ABI default there and x87 excess precision cannot occur - so restricting it
to x86 changes no behavior on existing targets while making the rest build.
The Eigen backend only implements the NHWC float32 path and hard-errors on
NCHW (eigenbackend.cpp:2425) and on FP16 (eigenbackend.cpp:2663). Nothing
compensated for that: TestCommon::overrideForBackends only knew about OpenCL
and TensorRT, and testsearchmisc.cpp never called it at all. So every NN test
invoked with NCHW or FP16 args - which is how runsearchtestslimited.sh and
runsearchtests.sh invoke them - aborted with SIGABRT instead of running.

Clamp in the two startNNEval helpers instead of extending overrideForBackends:
they are the single choke point all NN tests go through, which also covers
testsearchmisc.cpp's runNNSymmetriesTest and runNNBatchingTest. Guarded by
USE_EIGEN_BACKEND, so other backends are unaffected.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant