Cortex-M: build for any Cortex-M variant against Corstone-300

[rascani]

Summary

Extend the Cortex-M test pipeline so the cortex-m<variant> target
strings registered in the AOT compile-config plumbing actually produce
runnable, ISA-faithful binaries. The binary is built end-to-end with
-mcpu=cortex-m<variant> — runner and core libraries alike — so
CMSIS-NN's compile-time __ARM_FEATURE_DSP / __ARM_FEATURE_MVE
selector exercises the matching kernel implementation. The Corstone-300
M55 simulator is an ISA superset of every earlier Cortex-M, so it
executes binaries compiled for older cores without modification — the
CI gate becomes "did the right CMSIS-NN code path execute correctly"
rather than "did per-CPU silicon behave as expected".

The build pipeline learns the target CPU end-to-end:

• build_executorch.sh accepts --target_cpu and passes -DTARGET_CPU
  to the toolchain CMake.
• build_test_runner.sh derives target_cpu from --target and
  forwards it. The regex matches both bare cortex-m<X> (the canonical
  form after the Phase 1 AOT API drop of +int8) and the legacy
  cortex-m<X>+int8 shape for any callers still on it.
• build_executor_runner.sh derives the matching target_cpu and
  supplies a dummy ETHOSU_TARGET_NPU_CONFIG=ethos-u55-128 so
  core_platform's ethosu_get_architecture() parser stays happy.

One transient patch is layered into the externally-fetched
ethos-u/core_platform repo via the existing patch_repo mechanism:
an #if defined(__ARM_ARCH_8M_MAIN__) || defined(__ARM_ARCH_8_1M_MAIN__)
guard around the MPU init block in corstone-300/target.cpp. Without
it, the Armv8-M-only ARM_MPU_RBAR / ARM_MPU_RLAR API breaks the
build for older cores. The FVP doesn't enforce protection regions
without an explicit setup, so simulation correctness is unaffected.
The patch is a bridge — see TODO at corstone_utils.cmake:52 —
pending upstream merge of the equivalent guard.

Inside our own runner, the optional Armv8.1-M PMU intrinsics
(ARM_PMU_*) in arm_executor_runner.cpp and arm_perf_monitor.cpp
are guarded on __ARM_ARCH_8_1M_MAIN__. Earlier cores get a zero
cycle count rather than a compile error; functional correctness is
unaffected. run_fvp.sh routes all cortex-m* targets except
cortex-m85* to the Corstone-300 FVP.

Test Plan

Locally validated end-to-end on Corstone-300 with the qadd model:

• cortex-m55 — baseline, PASS; op_quantize_per_tensor.cpp.obj
  contains MVE intrinsics (vdup.16, vmax.s16).
• cortex-m4 — PASS; same object has no MVE — only single-precision
  FP (vmul.f32, vcvt.s32.f32). CMSIS-NN selects the DSP path (1275 DSP
  opcodes in libcmsis-nn.a).
• cortex-m7 — PASS; same shape as M4.

Scalar-class variants (cortex-m{0,0plus,3,23}) still need a
follow-up: an Armv6-M HardFault_Handler guard in target.cpp and a
core_software/cmsis.cmake ARMCM0plus directory-case fix. The
target_cpu plumbing here already accommodates soft-float ABI builds —
the follow-up only adds those two additional __ARM_ARCH_* guards.

Authored with Claude.

cc @digantdesai @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/19520

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Run pull request jobs on OSDC runners in shadow mode

❌ 1 New Failure, 1 Cancelled Job

As of commit 8b8ce9e with merge base 8e8e957 ():

NEW FAILURE - The following job has failed:

• pull / android / run-emulator (gh)
  The process '/usr/bin/sh' failed with exit code 1

CANCELLED JOB - The following job was cancelled. Please retry:

• trunk / test-models-linux-aarch64 (phi_4_mini, portable, linux.arm64.m7g.4xlarge) / linux-job (gh)
  ##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[mansnils]

LGTM. I like the direction this draft PR is going..