Add OSS CI to cross-compile and run the Cadence Xtensa backend (#20208)

[aliafzal]

Summary:
Adds OSS CI to cross-compile and run the Cadence (Xtensa) backend, so backend changes can be validated in CI rather than only through internal flows.

• gflags-free ISS runner (cadence_executor_runner): the upstream executor_runner can't cross-compile to Xtensa (gflags pulls in mkdir(2), absent from Xtensa newlib). This uses argv-only parsing like the Arm/NXP backends, loads a .pte, and runs the first method on the simulator. Also registers the quantized_depthwise_conv1d ops the HiFi4 codegen references but the operators CMake omitted (broke the link).
• xtensa-build job added to the existing Cadence Build & Test workflow (build-cadence-runner.yml), alongside the host cpu-build/cpu-test. It cross-compiles the runner for the hifi4 and vision cores and uploads it; an ISS test stage follows later (cf. cpu-build -> cpu-test). The licensed toolchain/core artifacts are fetched at runtime from an auth-gated store via a short-lived OIDC credential; role/region/store are supplied via CI variables and are not committed.

Test Plan: Validated locally end to end: setup + cross-compile produce an Xtensa ELF runner for vision; the HiFi4 op sweep passes 15/15 on the simulator and a trivial model returns the expected output.

Differential Revision: D108258574

Pulled By: aliafzal

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 5 New Failures, 21 Pending

As of commit 8f285c8 with merge base 0807724 ():

NEW FAILURES - The following jobs have failed:

• pull / test-arm-backend-no-driver (test_pytest_ops_tosa) / linux-job (gh)
  RuntimeError: Command docker exec -t 1bbcd3b18b9276dbe02cfdf4eece7bd3991c7f2e82d40bc55320ac1b3c4c6523 /exec failed with exit code 1
• pull / test-samsung-quantmodels-linux / linux-job (gh)
  RuntimeError: Command docker exec -t feec0d1cf3eaaf679738640d6905ce5071c3a2e3a0a38a57abfeb050cddcf5c0 /exec failed with exit code 1
• Test QNN Backend / test-qnn / test-backend-linux (qnn, operators) / linux-job (gh)
  RuntimeError: Command docker exec -t f7dfb7e379bb220ea52e5399f3df389f2bbf9674d15d61eeb525f4223ffa6a3f /exec failed with exit code 92
• trunk / test-qnn-optimum-model (fp32, roberta) / linux-job (gh)
  RuntimeError: Command docker exec -t 60b63ba29ad4c2d7aff1a94aaee8084d9a0eb2637482223716c1e3ba2be356e7 /exec failed with exit code 92
• trunk / test-qnn-optimum-model (fp32, swin) / linux-job (gh)
  RuntimeError: Command docker exec -t 04f1e01d9ce3cc66079ff190ff21e1eb0c117145b48d532ce4efbc9811c40f20 /exec failed with exit code 92

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

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[meta-codesync]

@aliafzal has imported this pull request. If you are a Meta employee, you can view this in D108258574.

[meta-codesync]

@aliafzal has exported this pull request. If you are a Meta employee, you can view the originating Diff in D108258574.

[rascani]

@claude review this PR

[claude]

Claude finished @rascani's task in 4m 13s —— View job

---

PR Review: Add OSS CI for Cadence Xtensa backend

• Read changed files
• Review CI workflows & scripts
• Review C++ runner & CMake changes
• Post review feedback

Nice, well-documented change — the inline comments explaining why (gflags→mkdir, double-registration of cadence_ops_lib, gzip-trailing-garbage, OIDC-on-host) are genuinely helpful and answer most of the questions a reviewer would otherwise raise. Below are the things worth addressing before merge.

---

Workflow / CI

1. xtensa-build runs on every pull_request, but depends on the cadence environment + AWS OIDC. (build-cadence-runner.yml:58-74)
Fork PRs from external contributors won't have access to the cadence environment, vars.CADENCE_CI_*, or the OIDC role, so hifi-build/vision-build will fail for every external PR (and environment protection rules may also block them). Consider gating these jobs to the main repo, e.g.:

hifi-build:
  if: github.repository_owner == 'pytorch'

Otherwise the red X on fork PRs will be noise. Fix this →

2. CodeQL: no top-level permissions block (build-cadence-runner.yml)
Two CodeQL findings (227/228) flag the missing default-permissions. The individual jobs set permissions: correctly, but the workflow has no top-level default. Add:

permissions: {}

near the top (after concurrency:), then keep the per-job blocks. This closes both alerts.

Note: I can't push edits to files under .github/workflows/ myself (the GitHub App lacks workflow-modify permission), so items 1 & 2 need a manual commit.

---

C++ runner (cadence_executor_runner.cpp)

3. Output printing assumes float dtype (cadence_executor_runner.cpp:190)

const float* p = t.const_data_ptr<float>();

This unconditionally reinterprets every tensor output as float. For the add.pte smoke model that's correct, but the moment this runs a quantized Cadence model (int8/uint8 outputs — the whole point of the backend) the printed values will be garbage. Since the file's purpose is exercising Cadence quantized ops, consider at least branching on t.scalar_type() or noting the limitation. Not a blocker for the smoke test, but worth a guard or a comment.

4. PRIx32 without an obvious <cinttypes> include (cadence_executor_runner.cpp:110,158,177)
PRIx32 is used but neither <cinttypes> nor <inttypes.h> is included directly, and I couldn't find it transitively in the executorch headers the file pulls in. It evidently compiled in your toolchain (so something brings it in), but relying on a transitive macro is fragile across toolchain versions — adding #include <cinttypes> would make it robust.

5. Minor: inconsistent error formatting. Lines 110/158/177 print the error with 0x%" PRIx32 passing the Error enum directly (underlying type is uint32_t, so this is fine), while lines 128-131 and 169-171 use (unsigned int)...error() with %x. Harmless, but picking one style would read cleaner.

---

Scripts

6. Empty sed pattern risk in params rewrite (setup-xtensa-tools.sh:127-134)

TOOLS_PFX=$(sed -n 's/^install-prefix = //p' "${PARAMS_SRC}" | head -1)
...
sed -e "s|${TOOLS_PFX}|${TOOLCHAIN_HOME}|g" ...

If any of TOOLS_PFX / TOOLSUB_PFX / CFG_PFX comes back empty (params format drift, renamed key), the resulting sed -e "s||REPL|g" reuses the last regex (or matches the empty string), silently corrupting the params file rather than failing. Given set -euo pipefail won't catch this, an explicit non-empty check would fail fast with a clear message:

: "${TOOLS_PFX:?could not parse install-prefix from ${PARAMS_SRC}}"

Fix this →

7. fusion_g3 is defined but unbuildable. The case in setup-xtensa-tools.sh:56 and the usage string both advertise fusion_g3, while build-cadence-runner.yml:57 correctly notes it's omitted (nnlib API skew, runner doesn't link). That's fine, just make sure the divergence is intentional — a user running the setup script manually for fusion_g3 will succeed at setup then hit a link failure. The CMake comment at CMakeLists.txt:130 already accounts for -lidma on fusion_g3, so the intent to support it later is clear.

---

CMake — looks good

• The double-registration warning at CMakeLists.txt:117-121 (no --whole-archive) is the right call and well explained.
• Conditional -lidma only for vision/fusion_g3 (:130-132) is correct.
• The two added op_quantized_depthwise_conv1d_{ncl,nlc}.cpp entries (hifi/operators/CMakeLists.txt:137-138) match existing files and fix the link gap as described. ✅

---

Summary

No correctness blockers in the build path itself. The highest-value fixes are #1 (fork-PR gating) and #2 (CodeQL permissions) since they affect every PR's CI signal — both require a manual workflow-file edit. #3 (float-only output) and #6 (sed guard) are robustness improvements worth doing while the file is fresh.

[rascani]

This largely looks good to me. Claude had some good feedback, but I'd also add on that we may want to consider starting this workflow on nightly or trunk and then moving it up to pull once it proves stable.

[rascani]

Forgot to add - Thank you so much for putting this together @aliafzal. I'm really excited about having this in OSS.

[huydhn]

The CI looks good to me! I leave the rest of the PR for the team to review

[huydhn]

Just to note that being able to access to this environment means being able to access the S3 bucket. The access can be granted in several ways:

• Explicit approvals
• Branches, only allow certain branches like main to run the job