Arm backend: Add pass order validation to ArmPassManager

[martinlsm]

Introduce a mechanism to enforce required ordering of passes in ArmPassManager. Each ArmPass must now declare which passes are required to run after it, ensuring ordering constraints are always upheld.

This prevents accidental breakage when modifying pass ordering in the manager.

Ordering constraints are verified by the new method ArmPass.validate_constraints_mandatory. We considered reusing torch.fx.passes.infra.pass_manager.PassManager.validate_constraints, but that utility only checks pairwise ordering and cannot enforce that a pass is actually run, which did not meet our needs.

This patch only implements the mechanism and tests for it. Defining the actual pass orderings are done in a later patch.

Test plan

The change comes with added unit tests in backends/arm/test/misc/test_pass_required_order.py

cc @digantdesai @freddan80 @per @zingo @oscarandersson8218

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures, 2 Unrelated Failures

As of commit 243d006 with merge base 5fd66ee ():

NEW FAILURES - The following jobs have failed:

• pull / test-samsung-models-linux / linux-job (gh)
  RuntimeError: Command docker exec -t 610ee78b7122d70fb0b44c09566eb8f4f2e3c37ab6771ff32c4345091ea1077e /exec failed with exit code 1
• pull / unittest-editable / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_conv2d.py::TestConv2d::test_fp16_conv2d
• trunk / test-torchao-huggingface-checkpoints (qwen3_4b) / linux-job (gh)
  RuntimeError: Command docker exec -t e42415f96b30a0121391167e3db2dd9310d565f28abeb26ee8503714d52d959b /exec failed with exit code 2

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

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

• trunk / unittest-release / linux / linux-job (gh) (trunk failure)
  [ FAILED ] LoggingTest.Utf8Truncation
• trunk / unittest-release / macos / macos-job (gh) (trunk failure)
  [ FAILED ] LoggingTest.Utf8Truncation

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

[martinlsm]

@pytorchbot label ciflow/trunk

[martinlsm]

@pytorchbot label "partner: arm"

[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.

[digantdesai]

One issue I can see with this approach is transitive dependency and running into weird errors.

At a high level, do we see many cases where we run same pass multiple times in certain order for a given backend, or do something different, in terms of pass ordering, based on some flag or a model architecture?

[martinlsm]

I'm not fully understanding the case of transitive dependencies. With this implementation, if we got the following scenario:

PassA:
    _passes_required_after = {PassB}

PassB:
    _passes_required_after = {PassC}

PassC:
    _passes_required_after = set()

Then PassA will transitively depend on PassC.

Then if create a pipeline where we remove PassB like this:

[
    PassA,
    PassC,
]

Then we will get the following error:

The following constraints for passes are not met:
    PassB must run after PassA

Is that not an reasonable way to handle it? I cannot think of a case where a missing transitive dependency will slip through here and not get caught by validate_constraints_mandatory.

Then regarding your second point: We have a long-term plan to change the passes such that they will always be added in the same order, but let themselves check whether they should run or not. This means that the order will always remain the same no matter which state/hardware profile we are in. Does that answer your question or maybe I'm not fully following?

[digantdesai]

Is that not an reasonable way to handle it?

Yeah I guess. Thanks. I was also thinking like,

PassA --(needs)--> Pass B
PassB --(needs)--> Pass C
PassC --(needs)--> Pass A

More broadly,

let themselves check whether they should run or not

I am failing to see the gain from this added complexity over a list[Pass] for a given backend. Mainly because this is not a user facing surface.

[digantdesai]

If you are saying we don't have to maintain "per backend + config list of passe" perhaps that is a good enough reason to embrace this complexity.. But I doubt if we can get rid of backend "specialized" logic from the PassManager but happy to be proven wrong :)

[martinlsm]

Thanks @digantdesai for the thorough review and feedback!

Regarding the cycles, yes, this implementation would not be able to handle that. But we also want to avoid those kind of loops, so having circular dependencies such as that is something we want to avoid. I cannot say it's 100% future proof but it's unlikely that we would ever need cyclic dependencies I'm thinking.

Regarding the added complexity, perhaps it adds a bit yes; the idea is to uphold intended ordering of the passes in cases where a developer wants to change the ordering. It's not obvious what should come before/after what when there's so many of them. One could say that the unit tests should protect against improper reordering, but this feature gives us quicker and clearer feedback in those cases.

I see your argument about special cases might work against this design. In the worst case we would have to revisit this feature and try to extend/change it somehow. But we do hope to eliminate special cases and always list the passes in the same order at least.

[digantdesai]

_passes_required_after being empty for almost all existing passes implies that a simple (ordered) list is sufficient :)
I don't want to block you here, and since this is inside Arm dir, I will let you make the call. Thanks for the discussion.

[martinlsm]

Thanks! I see your point, but the actual dependencies are added in a later patch that is on its way.

[digantdesai]

stamping to unblock from merging if/when ready. Thanks @martinlsm

[zingo]

Test fails seems unrelated