Skip to content

Ship the XNNPACK delegate as its own library - #21526

Open
shoumikhin wants to merge 65 commits into
gh/shoumikhin/80/headfrom
gh/shoumikhin/81/head
Open

Ship the XNNPACK delegate as its own library#21526
shoumikhin wants to merge 65 commits into
gh/shoumikhin/80/headfrom
gh/shoumikhin/81/head

Conversation

@shoumikhin

@shoumikhin shoumikhin commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

The XNNPACK delegate is what makes many models run fast on CPU. Today
it is compiled into whichever component links it, so the wheel carries two copies and a C++
application cannot use it at all without building from source.

before:
  _portable_lib.so     contains its own copy of the XNNPACK delegate
  training extension   contains another copy
  your C++ app         cannot use the delegate without building from source

after:
  executorch/lib/libexecutorch_xnnpack_backend.so.1     one delegate
    both extensions and your app link the same one

How you use it

find_package(executorch REQUIRED)
target_link_libraries(my_app PRIVATE executorch::runtime executorch::xnnpack_backend)

One detail worth knowing: a delegate registers itself when its library loads, and nothing in
your program calls into it directly. A normal link would therefore drop it as unused, so the
target carries the linker options that keep it. You do not have to do anything for that to
work, but it is why linking the target is enough and no explicit registration call is needed.

Tested

Built the wheel on Linux x86_64 and aarch64, installed it into a clean environment, and
confirmed by symbol inspection that exactly one shipped library defines the delegate. Linked a
C++ application against the component, confirmed the delegate survives the link and registers
itself, and ran a delegated model. Existing Python tests pass unchanged.

[ghstack-poisoned]
@pytorch-bot

pytorch-bot Bot commented Jul 31, 2026

Copy link
Copy Markdown

🔗 Helpful Links

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

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

❌ 21 New Failures, 242 Pending, 1 Unrelated Failure

As of commit 78518c9 with merge base 6bbb75a (image):

NEW FAILURES - The following jobs have failed:

FLAKY - The following job failed but was likely due to flakiness present on trunk:

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

[ghstack-poisoned]
shoumikhin added a commit that referenced this pull request Jul 31, 2026
The XNNPACK delegate runs many models on CPU, but it is compiled into whichever
component links it. The wheel ships two copies today, one inside the Python
bindings extension and another inside the training extension, and a C++
application cannot get the delegate at all without building it from source.

Build the delegate as a shared library and ship it in the wheel, so a process
has one copy and both the Python bindings and a C++ application can link the
same one.

XNNPACK and its microkernels are built as static libraries, so they are bundled
inside this library rather than left for each consumer to supply. The runtime
and the thread pool are resolved from their shared libraries instead of
embedding another copy of either. Because the delegate now carries XNNPACK
itself, the places that used to name those static libraries explicitly no
longer do so when building shared, which would otherwise ship the same code
twice.

Registration still happens through a static initializer, and the delegate is
retained on the link line so that initializer runs even though no symbol from
it is referenced directly.

This is gated on the existing `EXECUTORCH_BUILD_SHARED` option, so only the
Linux wheel changes; iOS, Android, and embedded builds keep linking the static
library exactly as before.

Test plan:

The wheel smoke test now asserts that exactly one shipped library defines the
XNNPACK delegate, alongside the existing backend-registry, thread-pool, and CPU
kernel assertions. The symbol it checks was confirmed to exist in the shipped
libraries first, and the assertion was confirmed to fail against a wheel built
before this change, where it correctly reports both copies by name.

Built the wheel from a clean checkout and verified against a fresh virtual
environment with a normal dependency-resolving install:

- The wheel ships the delegate as its own versioned library next to the
  runtime, the thread pool, and the CPU kernels.
- `nm -DC` across every shipped shared object shows exactly one definition of a
  representative delegate symbol, in the new library rather than in the two
  extensions that used to carry it.
- The delegate still appears in the registered backend list at runtime, which
  confirms its static initializer still runs from the shared library.
- `.pte` execution through the Python bindings is unchanged, with outputs
  matching eager PyTorch.
- The backend-registry, thread-pool, and CPU kernel assertions all still hold
  with the new library loaded.
- With `EXECUTORCH_BUILD_SHARED` off, the delegate remains a static library and
  no new shared object is produced, so every build that does not opt in is
  unaffected.

ghstack-source-id: f241eb6
ghstack-comment-id: 5147561128
Pull-Request: #21526
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
[ghstack-poisoned]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ciflow/binaries/all Release PRs with this label will build wheels for all python versions ciflow/binaries ciflow/cuda ciflow/nightly ciflow/trunk CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants