Skip to content

Conversation

@albi3ro
Copy link
Contributor

@albi3ro albi3ro commented Oct 24, 2025

Context:

Trying to improve our integration between pennylane transforms and catalyst passes.

See #2206 for where we are able to update all built-in catalyst passes to be transforms instead. That PR helps validate we can make this change with no breaking behaviour.

Going forward, we can setup a plan to get rid of the catalyst-specific pass handling infrastructure.

Also note that this PR targets the PennyLane branch, so we can confirm we won't need anymore changes there to get catalyst working correctly before approving and merging.

Description of the Change:

Uses the transform.pass_name property as the higher priority source of the pass_name.

Updates the pass_pipeline from the quantum_kernel_p primitive to be a tuple of TransformContainer objects instead of Pass, but leaves in the logic to handle tuple[Pass,...] for safer backwards compatibility.

Also makes using transforms with pass names by splitting a QNode's transform program into "things at the start of the program that are tape transforms" and "things at the end of the program that are MLIR passes". This will allow us to get rid of PassPipelineWrapper use for both systems and soften the change from old frontend to new frontend.

Benefits:

Unified handling of transforms across pennylane and catalyst.

Possible Drawbacks:

Related GitHub Issues:

Depends on PennyLaneAI/pennylane#8539 [sc-103775]

@codecov
Copy link

codecov bot commented Nov 17, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.50%. Comparing base (f930860) to head (9096ada).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2149   +/-   ##
=======================================
  Coverage   97.49%   97.50%           
=======================================
  Files          93       93           
  Lines       10886    10921   +35     
  Branches     1038     1046    +8     
=======================================
+ Hits        10613    10648   +35     
  Misses        211      211           
  Partials       62       62           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@github-actions
Copy link
Contributor

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.md on your branch with:

  • A one-to-two sentence description of the change. You may include a small working example for new features.
  • A link back to this PR.
  • Your name (or GitHub username) in the contributors section.

@paul0403
Copy link
Member

Don't forget changelog (we can probably just add this one to the single transform primitive one)

Co-authored-by: Paul <79805239+paul0403@users.noreply.github.com>
Co-authored-by: Paul <79805239+paul0403@users.noreply.github.com>
Copy link
Contributor

@mudit2812 mudit2812 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great to me! I'll let the compilation team be the final approvers here

Comment on lines +323 to +330
def _lowered_options(args, kwargs):
lowered_options = {}
for arg in args:
lowered_options[str(arg)] = get_mlir_attribute_from_pyval(True)
for option, value in kwargs.items():
mlir_option = str(option).replace("_", "-")
lowered_options[mlir_option] = get_mlir_attribute_from_pyval(value)
return lowered_options
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like this functionality to be extended in the future to also allow a way to lower python objects that do not have a straightforward way of lowering to MLIR. This is necessary for some of the xDSL passes to work. It would be very cumbersome for the default pass decorators to use arguments that are MLIR compatible for complex passes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this has to be per-pass right? We don't know what python objects a xdsl pass might take in as options in general.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, passes would need to define their own strategies for serializing/deserializing, but the compilation pipeline will have to be updated to integrate with these strategies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants