From 9f47d6d15781d055896f314f27f9864598da73ae Mon Sep 17 00:00:00 2001 From: Ivaylo Enchev Date: Mon, 22 Sep 2025 15:23:30 -0700 Subject: [PATCH] Resolve host vs target num kernels issue for product et builds (#14365) Summary: Applying the max kernel num setting through a config/mode results in both host and target builds to limit number of kernels. This can result in a case where the host tooling is building with all ops/kernels but has the setting applied causing crashes on load. Host doen't (usually) have such memory limitation as target so adding select to disable the application of max kernel num when applying a host toolchain. Reviewed By: larryliu0820 Differential Revision: D82579896 --- runtime/kernel/targets.bzl | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/runtime/kernel/targets.bzl b/runtime/kernel/targets.bzl index 8a945f19881..92e30016f42 100644 --- a/runtime/kernel/targets.bzl +++ b/runtime/kernel/targets.bzl @@ -3,7 +3,10 @@ load("@fbsource//xplat/executorch/build:runtime_wrapper.bzl", "get_aten_mode_opt def _operator_registry_preprocessor_flags(): max_kernel_num = native.read_config("executorch", "max_kernel_num", None) if max_kernel_num != None: - return ["-DMAX_KERNEL_NUM=" + max_kernel_num] + return select({ + "DEFAULT": ["-DMAX_KERNEL_NUM=" + max_kernel_num], + "ovr_config//build_mode/constraints:arvr_is_host_platform": [] + }) elif not runtime.is_oss: return select({ "DEFAULT": [],