[metascroy]

Wires the Core AI bridge into an ExecuTorch BackendInterface so CoreAIBackend can load and run models (runtime/coreai_backend.mm).

• init parses the manifest, checks the OS floor, selects the platform/architecture assets, acquires a prepared model through the load coordinator and binds the named function with ordered inputs/outputs.
• execute validates dtype (FP16/FP32), CPU storage, default dim order and contiguity, borrows input bytes without copying, then validates and resizes every output before copying any results.
• init and execute block their calling thread on Swift concurrency work, so the README tells callers not to invoke them from Swift async code.
• Build: backends/apple/coreai/CMakeLists.txt builds coreaidelegate (static, or shared against executorch_shared) from the backend sources plus coreai_bridge_obj, linking coreai_swift with the C++ linker so ExecuTorch's C/C++ options never reach swiftc.
• Tests:
  • The fake bridge gains function binding, sessions, execution and the C entry points the backend calls, so the real backend runs in coreai_host_test (delegate suite).
  • coreai_runtime_smoke checks final linkage, registration retention and availability. With EXECUTORCH_BUILD_TESTS=ON it is built and registered with CTest; otherwise it stays out of the default build.
• README: execution semantics, device-architecture selection, the default assets root, "Runtime options", and delegate linkage in "Building".
• Changes outside backends/apple/coreai are CMake only and only take effect when EXECUTORCH_BUILD_COREAI=ON:
  • tools/cmake/preset/default.cmake: EXECUTORCH_BUILD_COREAI requires the data loader extension.
  • CMakeLists.txt: add coreaidelegate to the backend list.

Stack: 7 of 9, based on #23392. Review only this PR's commit. Next: #23394.

Test plan: built locally for macOS 27.0; ctest -N lists coreai_host_test, coreai_swift_bridge_test and coreai_runtime_smoke, which the Core AI workflow runs on the macOS 27 runner. The smoke binary needs OS 27, so it only runs there (first CI run of it). lintrunner is clean.

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 1 Cancelled Job, 1 Unclassified Failure

As of commit d07e206 with merge base 61ec450 ():

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

• Core AI / test-coreai / test-coreai (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  backends/apple/coreai/runtime/test/coreai_storage_test.mm:167:23: error: code should be clang-formatted [-Wclang-format-violations]

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

• Build Presets / linux (linux, mt-l-arm64g4-16-62, executorch-ubuntu-22.04-gcc11-aarch64) / build (gh)
  ##[error]received SIGINT

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

[metascroy]

@claude review this PR

[claude]

Claude finished @metascroy's task in 2m 21s —— View job

---

This PR wires the Core AI bridge into a CoreAIBackend BackendInterface. I found no blocking defects, but three things are worth changing: SDK and caller output mismatches return the wrong error code, a failed multi-output execute can leave earlier outputs resized over stale data, and the multi-output path has no test.

Detailed review

PR Review: #23393

Summary

This PR adds runtime/coreai_backend.mm (manifest parsing, OS and architecture preflight, acquisition and function binding in init, and borrowed-input execution with validated output copy in execute), the coreaidelegate CMake target, a link/registration smoke binary, and a delegate suite running against the fake bridge. The three findings below are not blockers.

API Design

• Output mismatches return Error::InvalidExternalData (coreai_backend.mm:168-203). runtime/core/error.h:91 defines this code as "Error caused by the contents of external data", meaning named data or .ptd contents. Here it covers two other cases:

  • The SDK returns bad results (wrong output count, shape or byte count). This is a backend or SDK failure, so Error::Internal fits better.
  • The caller passes an output tensor with the wrong dtype or rank (HalfDtypePreservesBitsAndRejectsMixedOutputDtype, ScalarTensorsExecuteAndRejectOutputRankMismatch). This is the caller's fault, so it should be InvalidArgument. The dtype case can also be caught before running inference. validate_arguments already checks each output dtype against FP16/FP32, but never against the model's dtype, so a wrong output dtype costs a full inference before it is rejected.

  Once these codes ship they become part of the backend's documented behaviour, so it is easier to fix them now. Fix this →

Code Quality

• A failed execute can leave some outputs resized but not written (coreai_backend.mm:205-219). The comment says all outputs are checked before copying to avoid partial writes, but the second loop calls resize_tensor for each output as it goes. Suppose output 0 resizes successfully and output 1 then fails resize_tensor or the storage check. Output 0 keeps its new shape but still holds stale data, so the caller sees a shape that does not match its contents. This only matters with more than one output. Two fixes:
  • Check capacity and dynamism for every output before calling resize_tensor on any of them.
  • Or narrow the comment to say only data writes are all-or-nothing.

Testing

• The multi-output path is never tested. valid_binding in coreai_fake_loader.mm accepts only @[@"input_0"] / @[@"output_0"], and FakeSession executeInputs: always returns a single tensor. The parts of copy_outputs that exist for more than one output (the separate shape-validation and resize loops) therefore never run. Ordered input/output mapping is also never checked: nothing catches outputs copied into the wrong slot or inputs sent in the wrong order. A two-input, two-output fake case would cover this, ideally one where output 1 is too large for its capacity, to pin down the behaviour in the previous finding.

Recommendation

Approve (once the error codes are settled). None of these findings blocks the PR. The error-code change is the one to make before merge, because the codes become observable behaviour.

[metascroy]

@claude review this code

Updated head: ed11289d6a896c0051acfa8f2b2ff976112f0aee. The stack and parent PR have been refreshed; please review against the current base.

Context on the previous findings: output failure handling is deliberately not transactional. Earlier output shapes may change before a later resize fails, but no result bytes are copied unless every output validates and resizes successfully. Callers must not use outputs as inference results after an error. We documented and tested this contract rather than adding shape rollback or duplicating runtime resize rules. Rejecting output dtype mismatches before inference would require model-output metadata the current handle does not expose; that bridge expansion was not necessary for the error-classification fix. Malformed SDK outputs now use Internal, incompatible caller outputs use InvalidArgument, and native multi-input/output ordering and later-output-failure tests were added.

[claude]

Claude finished @metascroy's task in 3m 43s —— View job

---

The follow-up commit addresses all three earlier findings and matches the contract you described, so there are no blockers left. What remains is minor: one output error code that still escapes the new split, the CTest registration and build wiring for the smoke test, two tests that pass on leftover state, and a stale README section.

Detailed review

PR Review: #23393

Summary

This PR adds the CoreAIBackend delegate (init/execute over the Core AI bridge), the coreaidelegate CMake target, a smoke binary for linkage and registration, and a delegate suite that runs against the fake bridge. The changes in ed11289 match the stated contract: malformed SDK outputs return Internal, caller dtype/rank mismatches return InvalidArgument, no bytes are copied unless every output resizes, and multi-input/output ordering is now tested. The findings below are all minor.

API Design

• resize_tensor errors are passed through unchanged (runtime/coreai_backend.mm:213). The new split says incompatible caller outputs return InvalidArgument, and the dtype/rank check (:207) and the storage check (:222) do. But if the caller gives a static-shape output and the SDK returns a different shape, execute returns whatever resize_tensor returns (NotSupported for static tensors). LaterOutputResizeFailureLeavesResultBytesUntouched (coreai_delegate_test.mm:346) pins that down. Either map this error to InvalidArgument too, or state in the README that resize errors pass through, so callers know they can get both codes for the same mistake.

Infrastructure

• CTest registers coreai_runtime_smoke on hosts that can't run it (CMakeLists.txt:364-367). add_test only checks EXECUTORCH_BUILD_TESTS. The other OS 27 tests also require CMAKE_SYSTEM_NAME STREQUAL "Darwin", which this one doesn't. Two cases fail:

  • An iOS cross-build with tests on registers an iOS binary in the host's CTest.
  • A macOS 26 host running the README's ctest --test-dir …/backends/apple/coreai launches an SDK27 binary.

  Both contradict the README (:268 "Do not execute SDK27 binaries on an older host", :277 "omitted for Apple cross-builds"). Add the Darwin condition, and consider a host-version gate or SKIP_RETURN_CODE.

• The preset makes the data loader mandatory, but the delegate never uses it (tools/cmake/preset/default.cmake:443-445, CMakeLists.txt:338,352). Nothing under backends/apple/coreai/runtime/ references DataLoader or extension/data_loader. Even so, EXECUTORCH_BUILD_COREAI=ON without EXECUTORCH_BUILD_EXTENSION_DATA_LOADER is now a configure error, and the static build links extension_data_loader into an exported target. The shared build already sets it to empty. If the data loader is only for consumers (Module/runners), drop the rule and the link. If something later in the stack needs it, add it there.

• coreaidelegate is missing from optional_lib_list (tools/cmake/executorch-config.cmake:98-140). The PR installs and exports the target and adds it to the backend list, but find_package(executorch) consumers who link ${EXECUTORCH_LIBRARIES} never get it. coremldelegate and mlxdelegate are both in that list. This is a one-line addition.

Testing

• BorrowedInputStorageStaysLiveUntilSuccessOrError checks leftover values on the error iteration (coreai_delegate_test.mm:450-477). tensors and bridge.state() carry over from the success iteration. observed, last_input_bytes and last_input_first_byte are never reset, so in the failure == true iteration those checks pass even if the fake never read the input. The input-still-live-on-error claim then rests only on the premature/finished timing checks. Reset the state, or write a different first input byte before each iteration.
• EmptyVectorAndMatrixBorrowNullStorage can pass without running inference (coreai_delegate_test.mm:596-614). Its only check is last_input_bytes == nullptr, which is also the initial value. If execute gained an early return for zero-byte tensors, the test would still pass. Assert that the execution count goes up, or set last_input_bytes to a non-null sentinel first.

Code Quality

• README "Host Tests" is out of date (README.md:272-277). It still says coreai_host_test covers "manifest parsing, AOT asset selection, and filesystem storage … without Swift or CoreAI SDK calls". The suite now also runs init/execute against the fake bridge. The ctest command in that section also runs coreai_runtime_smoke, which links Swift and the Core AI framework, and the section doesn't mention it.

Recommendation

Approve. Nothing blocks. The cheapest fixes to make before merge are the Darwin gate on add_test and the optional_lib_list entry. The data-loader rule depends on whether something later in the stack needs it.