google / google/ruy

Windows ARM64 link failure with the pinned cpuinfo revision

Open
#378 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
325
Forks
97
PR merge metrics
No merged PRs in 30d

Description

## Summary

A native Windows ARM64 build using Ruy's default cpuinfo integration fails at link time because Ruy pins a cpuinfo revision from before Windows ARM64 support was implemented.

The current workaround in #377 disables cpuinfo entirely on Windows ARM64. Although this allows the build to link, it also disables runtime CPU feature detection and makes `CpuInfo::NeonDotprod()` always return false. Updating the pinned cpuinfo dependency would be preferable.

## Environment

- Windows 11 ARM64, running natively
- Visual Studio 2022 17.14
- MSVC 19.44
- Windows SDK 10.0.26100.0
- CMake 3.31.6
- Ruy commit: `363f252289fb7a1fba1703d99196524698cb884d`
- Pinned cpuinfo commit: `082deffc80ce517f81dc2f3aebe6ba671fcd09c9`

The pinned cpuinfo commit is dated June 17, 2022.

## Failure

When Ruy is linked into a native Windows ARM64 CMake build, the final link fails with:

```text
ruy_cpuinfo.lib(cpuinfo.obj) : error LNK2019:
unresolved external symbol cpuinfo_isa referenced in
ruy::CpuInfo::NeonDotprod()
```

The failure was reproduced while building CTranslate2 with:

```text
cmake -A ARM64 \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_CLI=OFF \
-DWITH_MKL=OFF \
-DWITH_DNNL=OFF \
-DWITH_RUY=ON \
-DWITH_CUDA=OFF \
-DOPENMP_RUNTIME=COMP \
..
```

## Root cause

The pinned cpuinfo revision declares the ARM `cpuinfo_isa` symbol in `include/cpuinfo.h`, but only defines it in the Linux and Mach ARM implementations.

Its CMake configuration recognizes `Windows` and `arm64` independently, but does not add an ARM Windows initialization implementation. The resulting cpuinfo library therefore does not define `cpuinfo_isa`.

Windows ARM64 support was added to cpuinfo after the revision currently pinned by Ruy. Relevant upstream changes include:

- pytorch/cpuinfo#166 — Fix ISA detection on ARM64 Windows
- pytorch/cpuinfo#220 — Add Windows on Arm build support and detection tests

## Current workaround

google/ruy#377 disables `RUY_HAVE_CPUINFO` and removes the cpuinfo link dependency specifically on Windows ARM64.

This makes the build and native ARM64 inference tests pass, but it also causes Ruy to:

- use conservative hard-coded cache sizes;
- report `NeonDotprod()` as unavailable;
- potentially skip the optimized ARM64 dot-product path.

For this reason, the workaround does not appear suitable as the preferred long-term fix.

## Requested resolution

Would it be possible to:

1. update Ruy's cpuinfo submodule to a revision that supports Windows ARM64;
2. validate both the CMake and Bazel integrations on Windows ARM64;
3. add a native Windows ARM64 CI build or link test;
4. keep `RUY_HAVE_CPUINFO` enabled so runtime cache and ISA detection remain available?

If updating cpuinfo is currently blocked by compatibility requirements, an explicit build option for disabling cpuinfo would still be preferable to a hard-coded Windows ARM64 platform exception.

## Validation already completed

With cpuinfo disabled as in #377:

- Ruy links successfully in a native Windows ARM64 CTranslate2 build;
- multithreaded INT8 inference returns the expected result;
- the generated DLL and Python extension are native ARM64 (`AA64`);
- the installed-wheel test suite reports 82 passed and 89 skipped.

Related downstream PR: OpenNMT/CTranslate2#2086
Related workaround PR: google/ruy#377

Contributor guide

Open the contributing guide

Research direction

Start with Ruy's pinned cpuinfo submodule and its CMake and Bazel integrations, then compare revisions containing pytorch/cpuinfo#166 and #220. Reproduce the native Windows ARM64 link failure, validate an updated revision with cpuinfo enabled, and confirm the link, ISA detection, and native ARM64 inference tests pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, cpp
Domain
build-system, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.