Right-size operator registry from selective build metadata#19118
Right-size operator registry from selective build metadata#19118rascani wants to merge 1 commit intopytorch:mainfrom
Conversation
The runtime kernel registry is a fixed-size static array whose default capacity (MAX_KERNEL_NUM=2000) permanently occupies ~48 KiB of BSS even when only a handful of kernels are actually registered. When selective build is active the exact set of kernels needed by the model is already known at build time, so the registry can be sized to fit. A new codegen tool (gen_max_kernel_num.py) counts the (op, kernel_key) tuples in selected_operators.yaml, adds the prim ops registered by register_prim_ops.cpp, and writes the total into a generated header. operator_registry.cpp picks the header up via __has_include; a user-supplied -DMAX_KERNEL_NUM still takes precedence, and builds that don't use selective build keep the 2000 default. On examples/selective_build/basic with two selected ops, the registry's BSS footprint drops from 48000 B (2000 slots) to 840 B (35 slots) — a ~47 KiB reduction — with no additional flag required. Issue: pytorch#18618 Co-authored-by: Claude <noreply@anthropic.com>
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/19118
Note: Links to docs will display an error until the docs builds have been completed. ❗ 1 Active SEVsThere are 1 currently active SEVs. If your PR is affected, please view them below: ❌ 1 New Failure, 2 Unrelated FailuresAs of commit 97e49a4 with merge base 3ec63f4 ( NEW FAILURE - The following job has failed:
FLAKY - The following job failed but was likely due to flakiness present on trunk:
BROKEN TRUNK - The following job failed but was 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. |
This PR needs a
|
|
Can you attach a sample codegen header in the summary |
Done |
Summary
The runtime kernel registry is a fixed-size static array whose default capacity (MAX_KERNEL_NUM=2000) permanently occupies ~24 KiB of BSS on 32-bit machines even when only a handful of kernels are actually registered. When selective build is active the exact set of kernels needed by the model is already known at build time, so the registry can be sized to fit.
A new codegen tool (gen_max_kernel_num.py) counts the (op, kernel_key) tuples in selected_operators.yaml, adds the prim ops registered by register_prim_ops.cpp, and writes the total into a generated header. operator_registry.cpp picks the header up via __has_include. A user-supplied -DMAX_KERNEL_NUM still takes precedence, and builds that don't use selective build keep the 2000 default.
The below example demonstrates examples/selective_build/basic (two selected ops) on a 64-bit machine. The registry's BSS footprint drops from 48000 B (2000 slots) to 840 B (35 slots).
Fixes #18618
Example generated header: executorch/runtime/kernel/selected_max_kernel_num.h
Test plan
Expected output (BSS size is the 4-hex column after the address):