Skip to content

Ship the merged CPU kernels as their own library - #21524

Open
shoumikhin wants to merge 73 commits into
gh/shoumikhin/79/headfrom
gh/shoumikhin/80/head
Open

Ship the merged CPU kernels as their own library#21524
shoumikhin wants to merge 73 commits into
gh/shoumikhin/79/headfrom
gh/shoumikhin/80/head

Conversation

@shoumikhin

@shoumikhin shoumikhin commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

The CPU operator kernels are compiled into whichever component links
them. The Python extension therefore carries a full private copy, which makes it large, and a
C++ application cannot get the same operators without building them from source.

before:
  _portable_lib.so     contains its own copy of every CPU kernel
  your C++ app         cannot get them without building from source

after:
  executorch/lib/libexecutorch_optimized_native_cpu_ops_lib.so.1
    _portable_lib.so   -> links it
    your C++ app       -> links it

There is a correctness reason too, not just size. Operators register themselves into a table
when their library loads. Two copies in one process means two independent registrations of the
same operator set, and which one a model resolves to is then a matter of load order.

How you use it

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

The target name is the contract, not the file name. A model running the usual CPU operators
needs nothing else.

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 registers the CPU operator set.
Linked a C++ application against the component, ran a model through it, and ran the existing
Python tests so current users are unaffected.

[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/21524

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

❌ 24 New Failures, 269 Pending, 1 Unrelated Failure, 4 Unclassified Failures

As of commit 4cb6fbb with merge base b5239a5 (image):

NEW FAILURES - The following jobs have failed:

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

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

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

[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