Consolidation of Selective Build APIs for OSS

[BujSet]

🚀 The feature, motivation and pitch

Currently, there are three ways a user can enable the selective build process:

0. Disable selective build and include all operators.
1. Specify a string list of operators.
2. Provide a YAML file to enumerate which operators and dtypes should be included.
3. Provide a exported model (pte) to tailor the executorch build to the operators and tensor dtypes used in the model.

Right now, these APIs are treated as mutually exclusive, but there are use cases where a mixture of methods would be desirable. It would be ideal if there was a clearer/default way to enable selective builds without exposing too much of the configuration burden onto a user.

Example Use Case

A user wants to run two different models, where the second model only contains one differing operator. The user could determine the complete union of operators used by the two models, and manually specify them using the list API, but it would be easier if they could simply pass in one of the models and augment the selected operator set with the single differing operator (i.e. use the model API in conjunction with the list API).

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

[BujSet]

cc @lucylq @psiddh

[BujSet]

Along with this, it would also be cool if parsing the selective build method was something handle by a cmake tool, rather than relying on an user to explicitly notate which build format they want to use (e.g. all, list, json string spec (WIP here), yaml file path, model file path). I think the API could look something like:

DTYE_SELECTIVE_BUILD=<METHOD_STRING>

Where we do some checks to forward the cmake call e.g.:

• If the string is a simple Y or N, use the INCLUDE_ALL_OPS method
• If the string is a list of ops like aten::add.out,aten::_softmax.out", use the ROOT_OPS` method
• If the string is in a JSON string format, '{\"aten::add\":[\"v1/3;0,1|3;0,1|3;0,1|3;0,1\"],\"aten::mul\":[],\"aten::bmm\":[\"Float\"]}', use the OPS_FROM_DICT method (WIP here)
• If the string ends with ".pte" use the MODEL api

I think this would remove a lot of the user burden in determining which method of selective build they should use.

[arkadip-maitra]

Pushed first PR to only cover OSS CMake selective build correctness and test coverage. If this looks good, I’ll follow up with separate PRs for the consolidated selector API and docs/integration updates.

[ramyaravi1]

Is this issue still open? If so, I would like to work on this.

[TejasweeSulekh]

Hey @larryliu0820, @BujSet! I was looking into this issue to build out the feature, but when I dug into the codebase, I realized that the logic to merge these APIs is actually already fully functional.

If you look at the lines referenced in the original issue description, the assert statement uses or, which just ensures at least one method is provided, it doesn't actually block you from passing multiple. Today, if you pass both the model and a root_ops list down from CMake, gen_oplist.py seamlessly merges the extracted operators into a unified selected_operators.yaml without any errors.

@arkadip-maitra saw you have been working hard in PR #19443 to add the CMake end-to-end integration tests for this. Since that PR handles the heavy CMake bash testing, I went ahead and added the lightning-fast Python unit test directly into test_gen_oplist.py (PR #23176).

By having the core Python parser logic natively unit-tested, it locks in the behavior so it doesn't accidentally regress. Hopefully, having both the unit tests and the integration tests covered helps officially close out this issue!