NXP Backend: Add infrastructure for pre processing passes in edge dialect

[Pop-korn]

Summary

Add infrastructure for running pre-processing passes on edge dialect programs.
Add pre-processing pass to move view_copy nodes into their own QDQ clusters.

Test plan

Unit test provided.

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

✅ No Failures

As of commit 35c8809 with merge base c8a0706 ():
💚 Looks good so far! There are no failures yet. 💚

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

[Pop-korn]

@pytorchbot label "release notes: nxp" module "nxp backend"

[pytorch-bot]

Didn't find following labels among repository labels: module,nxp backend

[robert-kalmar]

You have introduced back the use of export_to_edge and edge_program_manager.to_edge functions, which were replaced by the to_edge_transform_and_lower function. The passes we introduce (edge passes) shall run after the export to edge dialect but before partitioning. The to_edge_transform_and_lower have optional parameter transform_passes which I suppose serves this purpose.
@Pop-korn, please update the code to use this call in the executorch_pipeline.py and aot_neutron_compile.py if feasible. This shall also resolve the conflict you have with the main branch.
Also rebase to the main. Then please mark the PR as ready to merge.

[Pop-korn]

I have resolved the conflict and re-based to main.

The to_edge_transform_and_lower parameter transform_passes only runs a single iteration of the passes. Therefore, if a pass makes a change that would allow an earlier pass to make another change, it will not get the chance to do so. The number of iterations is limited by the steps attribute of the PassManager, which cannot be set using the current interface. The only way to use a different steps value (that I know of) is to modify the class attribute directly (call PassManager.steps = 10 before calling to_edge_transform_and_lower), which is not god practice as it has a global effect.

I understand that the to_edge_transform_and_lower function is the preferred way for program lowering. So do we want to:

1. Use to_edge_transform_and_lower and only run the passes once.
2. Use to_edge_transform_and_lower and globally modify the steps class attribute, to run multiple iterations of passes.
3. Use the current implementation. I.e. manually export to edge, run the passes ourselves (unsing PassManager(steps=10)), and then explicitly export to backend (with partitioning).

Which of these solutions is preferred? Or is there a different solution I am not seeing? @digantdesai

[robert-kalmar]

@Pop-korn, in principal this does not differ from the initial draft. You return everytime, you make a modification and the caller EdgePassManager starts a new iteration. Can you do all the graph modification and return then?

@digantdesai, @Pop-korn noticed in some of the passes the code iterates over a changing graph. E.g. https://github.com/pytorch/executorch/blob/main/backends/xnnpack/_passes/fuse_batch_norm.py#L41 the graph.nodes gets modified in-place in the https://github.com/pytorch/executorch/blob/main/backends/xnnpack/_passes/fuse_batch_norm.py#L208, everytime a match is found.
@Pop-korn, can you please confirm? @digantdesai Is this legit and intended?

[Pop-korn]

Responding to the first paragraph:
We can safely to all the modifications at once, and then return. We would be modifying the list of nodes while iterating over it, but it shouldn't have negative side-effects as we are only inserting nodes. The downside is that is is not good practice. Do you think that implementation would be preferred?

The second paragraph:
As far as I can tell, the XNNPack batch_norm fusion pass does indeed modify the graph while iterating over it. When the pass removes a batch_norm node, the next iteration of the for loop will skip a node. If (somehow) the graph contained the sequence convolution -> batch_norm -> batch_norm, only the first batch_norm node would be fused, and the second one would be skipped.