Skip to content

Fix riscv generic target detection#87

Open
carlosqwqqwq wants to merge 1 commit into
tlk00:masterfrom
carlosqwqqwq:riscv-bitmagic
Open

Fix riscv generic target detection#87
carlosqwqqwq wants to merge 1 commit into
tlk00:masterfrom
carlosqwqqwq:riscv-bitmagic

Conversation

@carlosqwqqwq

Copy link
Copy Markdown

Why

BitMagic already has a portable non-SIMD baseline, but two parts of the project still inherit host-specific x86 assumptions during simulated or cross-target riscv64 builds:

  • src/bmdef.h derives BM_x86 and BM_UNALIGNED_ACCESS_OK directly from host compiler macros, which can leak x86 inline-assembly and memory-access assumptions into riscv64 target validation.
  • CMakeLists.txt injects -march=native by default for GNU/Clang builds, which is appropriate for native x86 builds but not for cross-target or simulated riscv64 configurations.

What changed

  • Update src/bmdef.h to recognize __riscv first and define BM_RISCV.
  • Prevent BM_x86 and BM_UNALIGNED_ACCESS_OK from being inferred when the selected target is RISC-V.
  • Update CMakeLists.txt so the default GNU/Clang path only applies -march=native for non-cross x86 targets, while non-x86 or cross-target builds fall back to generic -O2 flags unless an explicit SIMD profile is requested.
  • Update README.md to document that riscv64 should use the default portable build unless a dedicated RISC-V SIMD backend is added.

Verification

  • Preprocessed src/bmdef.h with forced __riscv=1 and __riscv_xlen=64 and confirmed BM_RISCV is defined while BM_x86 and BM_UNALIGNED_ACCESS_OK are no longer defined.
  • Compiled a forced-riscv64 smoke translation unit including bm.h and confirmed the generic path builds successfully without leaking x86-only assumptions.
  • Ran native Release CMake configuration with Ninja:
    • cmake -S . -B build-native-min -G Ninja -DCMAKE_BUILD_TYPE=Release
  • Built the native bmsvutil target successfully:
    • cmake --build build-native-min --target bmsvutil --parallel 4
  • Ran the produced utility and confirmed it starts and prints usage text:
    • build\bin\bmsvutil.exe
  • Ran a simulated riscv64 CMake configuration:
    • cmake -S . -B build-riscv-config -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=riscv64 -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
  • Inspected build-riscv-config/build.ninja and confirmed the generated compile flags no longer contain -march=native, -msse4.2, -mavx2, BMSSE42OPT, or BMAVX2OPT.
  • Cross-compiled the upstream samples/svsample10/svsample10.cpp example to a static riscv64 executable with -std=c++17.
  • Verified the produced executable with:
    • file
    • readelf -h
  • Ran the resulting binary under qemu-riscv64 and confirmed the expected scanner output is produced end-to-end.

Notes

This is a conservative portability patch. It does not add RVV or any other RISC-V SIMD backend. The goal is to keep riscv64 on BitMagic's existing generic implementation path and to stop host x86 configuration details from leaking into target selection and validation.

As of the 2026-06-19 fresh upstream sync audit, this branch is currently 1 ahead / 1 behind upstream/master. The missing upstream commit is a885ae4e (added is_all to when to test svf), which only touches tests/stress/t.cpp and does not overlap this patch's migration files (CMakeLists.txt, src/bmdef.h, README.md). A manual upstream PR should still be created from a rebased or otherwise synchronized branch, but the current drift is a branch-maintenance issue rather than evidence that the RISC-V patch itself has already gone stale.

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