Qualcomm AI Engine Direct - Adding QNN backend support for randn core ATen op

[qti-horodnic]

Summary

Added support for the randn core ATen op using the existing QNN backend implementation of RandomNormalLike. Note only INT8 outputs are supported.

Also fixed a minor bug in the rand op's implementation and test and removed the FP test as it doesn't serve a purpose since rand doesn't support FP outputs either.

Test plan

python backends/qualcomm/tests/test_qnn_delegate.py -k TestQNNQuantizedOperator.test_qnn_backend_randn --model 
SM8750 --host aisw-vm15-labsd --device 545ee4aa --build_folder build-android

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Run pull request jobs on OSDC runners in shadow mode

✅ You can merge normally! (2 Unrelated Failures)

As of commit 3f95804 with merge base 371cb1c ():

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / unittest / macos / macos-job (gh) (trunk failure)
  devtools/intermediate_output_tap/tests/test_coreml_e2e.py::CoreMLEndToEndTest::test_tap_compare_static_llama_coreml
• pull / unittest-editable / macos / macos-job (gh) (trunk failure)
  devtools/intermediate_output_tap/tests/test_coreml_e2e.py::CoreMLEndToEndTest::test_tap_compare_static_llama_coreml

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

[qti-horodnic]

@pytorchbot label "release notes: qualcomm"

[psiddh]

So, Before this PR, if a model contained torch.randn or torch.randn_like, the QNN partitioner had no builder for it, so it would not delegate that op to HTP, instead it would be running on CPU , causing potential perf degradation

[psiddh]

lgtm (mypy CI errors are unrelated)

[qti-horodnic]

So, Before this PR, if a model contained torch.randn or torch.randn_like, the QNN partitioner had no builder for it, so it would not delegate that op to HTP, instead it would be running on CPU, causing potential perf degradation

Yes, correct. All the prs which I called adding QNN backend support for ... op do this. If there's a direct implementation on the QNN side, support will be added via a builder as in this PR or #19283. If there isn't a QNN implementation, support will be added (if possible) via a decomposition pass breaking down the unsupported into ops which are supported, like for the tan op here.

Note that we are working on supporting most of the ops in the ATen core opset, so expect several more such prs over the coming weeks.