Refactor CPU feature detection to use an explicit x86 whitelist

[ihb2032]

Currently, cpu_features.cc assumes that any architecture that is not __ARM_ARCH must be an x86/x64 architecture and attempts to include <cpuid.h>. This causes fatal compilation errors on other architectures like RISC-V.
Changes Proposed
This PR refactors the preprocessor directives to use an explicit "whitelist" approach:

• <cpuid.h> and x86-specific CPUID logic are now only compiled when x86_64 or i386 is explicitly defined or under MSVC for Windows.
• All other architectures including ARM, RISC-V, etc. will safely fall back to the default initialization, allowing the project to compile successfully as generic C++ code.

Motivation
This resolves build failures on RISC-V environments and sets up a clean, safe foundation for potentially adding architecture-specific optimizations in the future.
closed #244

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[richyreachy]

hi @ihb2032, as we noticed that RISC-V is available on github runner (#244), could you please setup a CI job on it along with this PR?

[richyreachy]

@ihb2032 please take a look at this error: https://github.com/alibaba/zvec/actions/runs/24500696519/job/71607486150

Seems the ci job can be brought up after Github App was setup.

Any problem, let me know.

[ihb2032]

Hi @richyreachy, thanks for pointing that out!

I checked the logs and the issue is that actions/setup-python currently doesn't provide a pre-built Python 3.10 binary for the riscv64 architecture on Ubuntu 24.04.

To fix this without breaking the other builds that share 03-macos-linux-build.yml, I've updated the workflow to conditionally use Python 3.12 only when inputs.platform == 'linux-riscv64', while keeping the rest on 3.10.

I've just pushed the fix, let's see if the CI turns green!

[ihb2032]

Hi @richyreachy, the RISC-V CI failed due to a timeout. Would it be possible to split the build and test phases to prevent this?

[richyreachy]

Hi @richyreachy, the RISC-V CI failed due to a timeout. Would it be possible to split the build and test phases to prevent this?

There's hard timeout limit(6 hours ) for CI jobs. Since test stage depends on the outcome of build, it may need some effects to figure out how to shrink the process.

[ihb2032]

Hi @richyreachy,
To address the timeout while keeping the workflow stable, I'm thinking of a targeted optimization for the RISC-V build.
We could update the workflow to use the wheel provided by RISE for the cmake package, but only when the platform is linux-riscv64. For all other architectures, we’ll continue to use the standard packages from PyPI to ensure no regressions.
According to my estimate, this change could shave off nearly 1 hour from the RISC-V CI job. Does this conditional approach sound good to you?

[richyreachy]

Hi @richyreachy,

To address the timeout while keeping the workflow stable, I'm thinking of a targeted optimization for the RISC-V build.

We could update the workflow to use the wheel provided by RISE for the cmake package, but only when the platform is linux-riscv64. For all other architectures, we’ll continue to use the standard packages from PyPI to ensure no regressions.

According to my estimate, this change could shave off nearly 1 hour from the RISC-V CI job. Does this conditional approach sound good to you?

Yes. The workflow for RISC-V is slower compared to other architectures. Every measurement deserves a try for execution time optimization.