[Executorch] make slice_copy parallel

[kimishpatel]

Stack from ghstack (oldest at bottom):

• -> [Executorch] make slice_copy parallel #15830

When doing large prefills in LLMs, slice_copy takes about 5-10% time.
Mainly coming from slicing in the rope implementation.

Differential Revision: D85532081

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 2 New Failures

As of commit 4c5d92d with merge base 9cd8402 ():

NEW FAILURES - The following jobs have failed:

• pull / android / run-emulator (gh)
  Timeout waiting for emulator to boot.
• pull / unittest / macos / macos-job (gh)
  examples/models/test/test_export.py::ExportTest::test_mv3_export_to_executorch

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

[Copilot]

Pull Request Overview

This pull request adds parallel processing to the slice_copy operation in ExecutorTorch to improve performance during large prefills in LLMs, where slice_copy can take 5-10% of execution time (primarily from rope implementation slicing).

Key Changes:

• Added multithreading support to compute_slice function with workload-based thresholds
• Parallel execution distributes work across leading dimensions using parallel_for
• Single-threaded fallback maintained for smaller workloads

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
kernels/portable/cpu/util/targets.bzl	Adds threadpool dependency required for parallel execution support
kernels/portable/cpu/util/slice_util.cpp	Implements parallel slice_copy with multithreading when leading_dims ≥ 8 and total_elements ≥ 32768, maintaining single-threaded fallback for smaller workloads

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The variable elements_per_leading_dim is calculated but never used. It appears this was intended for grain size calculation but MIN_LEADING_DIMS_FOR_MT is used instead. Consider removing this unused variable or using it to calculate a more dynamic grain size based on workload characteristics.

Suggested change

const int64_t elements_per_leading_dim = length * trailing_dims;