TorchAO kernels ship on macOS arm64 only, not Linux aarch64

[shoumikhin]

What

The wheel ships libexecutorch_kernels_torchao on macOS arm64 only. Linux aarch64 has the NEON
hardware these kernels target and does not get them.

Verified against the published nightly 1.5.0.dev20260828, cp310, manylinux_2_28_aarch64:

libexecutorch.so
libexecutorch_backend_openvino.so
libexecutorch_backend_xnnpack.so
libexecutorch_etdump.so
libexecutorch_kernels_optimized.so
libexecutorch_kernels_quantized.so
libexecutorch_threadpool.so

No torchao kernels. The macOS arm64 wheel has libexecutorch_kernels_torchao.dylib.

Why it happens

EXECUTORCH_BUILD_KERNELS_TORCHAO is only turned on for Apple:

• tools/cmake/preset/apple_common.cmake:36 sets it ON
• tools/cmake/preset/llm.cmake:24 sets it ON only under Darwin and arm64
• tools/cmake/preset/pybind.cmake, which is the preset the wheel build uses, never sets it, and
  its Linux branch is an empty stub

So the exclusion is a preset decision rather than a technical limit at the ExecuTorch level:
torchao_ops_executorch in third-party/ao/torchao/csrc/cpu/CMakeLists.txt is declared outside any
architecture guard, and TORCHAO_BUILD_CPU_AARCH64 only adds an extra
target_link_libraries(torchao_kernels_aarch64).

Worth knowing before anyone "fixes" this by enabling it everywhere

It should not simply be turned on for x86. In
shared_kernels/linear_8bit_act_xbit_weight/kernel_selector.h, every return PackedWeightsFormat
is behind #if defined(TORCHAO_ENABLE_ARM_NEON_DOT) or TORCHAO_ENABLE_KLEIDI:

'return PackedWeightsFormat' inside ARM guards  : 4
'return PackedWeightsFormat' outside (portable) : 0

With no NEON define, select_packed_weights_format and select_packed_weights_with_lut_format
have no reachable return and fall through to
throw std::runtime_error("No packed_weights_format was selected"). The kernel registration table
similarly ends in "ukernel_config did not register". The torch_free_kernels/fallback directory is
header-only; its CMakeLists.txt only adds tests.

So enabling it on x86 would build and then throw on every torchao op, which is worse than omitting
it. Linux aarch64 is the case that looks genuinely worth enabling, since it satisfies the NEON
guards.

Ask

Is the Linux aarch64 omission intentional, or an oversight from the preset only ever being wired up
for Apple? If it is worth enabling, it needs a linux-aarch64 build plus a real lowbit export/run to
validate, which I could not do here: PR wheel runs publish x86_64 only, and aarch64 builds on the
nightly cron.

Found while auditing wheel contents across platforms (#22267, #22269, #22272 and related).

[shoumikhin]

Opened #22300 for the Linux aarch64 half of this.

Validated on real Linux aarch64 hardware rather than by reading: at the pinned TorchAO commit, libtorchao_kernels_aarch64.a builds with gcc 11.4, and kernel_selector.h (the header the ExecuTorch ops actually include) compiles clean under gcc with -march=armv8.4-a+dotprod. The gate turned out to be a single condition: the option is set inside the Darwin branch under CMAKE_SYSTEM_PROCESSOR STREQUAL "arm64", and Linux aarch64 reports aarch64.

x86 is left out for the reason in the issue above: every return PackedWeightsFormat is behind an ARM guard, so it would build and then throw on every op.

Leaving this issue open until #22300 lands, since it also records the two upstream TorchAO gcc portability bugs (embedding_lut.h missing <cstring>, test_bitpacking.cpp brace-initialising int8x16_t), which need fixing in the submodule and are not addressed by that PR.