Implement a decomposition of PPRs into PPMs #1664

sengthai · 2025-04-16T22:07:32Z

Context:
This PR introduces a new pass that decomposes Pauli Product Rotations (PPR) into Pauli Product Measurements (PPMs) consuming magic states. Two decomposition strategies are supported: inject-magic-state and auto-corrected. Related prior work on qec.ppr began in #1486 #1563 #1580.

Description of the Change:

New operation: qec.select.ppm – conditional Pauli product measurement based on a boolean control
New operation: qec.prepare – prepares logical qubits in a specified initial state (|0⟩, |1⟩, |+⟩, |-⟩, |Y⟩, |-Y⟩, |m⟩, or |m̅⟩)
Extended qec.ppr and qec.ppm to support conditional execution
Implemented decomposition strategies: inject-magic-state and auto-corrected.

Example:
Input:

func.func @test_ppr_to_ppm(%q1 : !quantum.bit) {
    %0 = qec.ppr ["Z"](8) %q1 : !quantum.bit
    return
}

Run:

$ quantum-opt --decompose_clifford_ppr='decompose-method=auto-corrected'  test.mlir

Outputs:

module {
  func.func @foo(%arg0: !quantum.bit) {
    %c2_i64 = arith.constant 2 : i64
    %0 = quantum.alloc(%c2_i64) : !quantum.reg
    %1 = quantum.extract %0[ 0] : !quantum.reg -> !quantum.bit
    %2 = quantum.extract %0[ 1] : !quantum.reg -> !quantum.bit
    %3 = qec.prepare  zero %1 : !quantum.bit
    %4 = qec.prepare  magic %2 : !quantum.bit
    %mres, %out_qubits:2 = qec.ppm ["Z", "Z"] %arg0, %4 : !quantum.bit, !quantum.bit
    %mres_0, %out_qubits_1:2 = qec.ppm ["Z", "Y"] %3, %out_qubits#1 : !quantum.bit, !quantum.bit
    %mres_2, %out_qubits_3 = qec.ppm ["X"] %out_qubits_1#1 : !quantum.bit
    %mres_4, %out_qubits_5 = qec.select.ppm(%mres, ["X"], ["Z"]) %out_qubits_1#0 : !quantum.bit
    %5 = arith.xori %mres_0, %mres_2 : i1
    %6 = qec.ppr ["Z"](2) %out_qubits#0 cond(%5) : !quantum.bit
    quantum.dealloc %0 : !quantum.reg
    return
  }
}

Run:

$ quantum-opt --decompose_clifford_ppr='decompose-method=inject-magic-state'  test.mlir

Outputs:

module {
  func.func @foo(%arg0: !quantum.bit) {
    %c2_i64 = arith.constant 2 : i64
    %0 = quantum.alloc(%c2_i64) : !quantum.reg
    %1 = quantum.extract %0[ 0] : !quantum.reg -> !quantum.bit
    %2 = qec.prepare  magic %1 : !quantum.bit
    %mres, %out_qubits:2 = qec.ppm ["Z", "Z"] %arg0, %2 : !quantum.bit, !quantum.bit
    %3 = quantum.extract %0[ 1] : !quantum.reg -> !quantum.bit
    %4 = qec.prepare  zero %3 : !quantum.bit
    %mres_0, %out_qubits_1:2 = qec.ppm ["Z", "Y"](-1) %out_qubits#0, %4 cond(%mres) : !quantum.bit, !quantum.bit
    %mres_2, %out_qubits_3 = qec.ppm ["X"] %out_qubits_1#1 cond(%mres) : !quantum.bit
    %5 = arith.xori %mres_0, %mres_2 : i1
    %6 = qec.ppr ["Z"](2) %out_qubits_1#0 cond(%5) : !quantum.bit
    %mres_4, %out_qubits_5 = qec.ppm ["X"] %out_qubits#1 : !quantum.bit
    %7 = qec.ppr ["Z"](2) %6 cond(%mres_4) : !quantum.bit
    quantum.dealloc %0 : !quantum.reg
    return
  }
}

[sc-89168]
[sc-90158]

…asurements based on a boolean control. - Added convenience builders. - Improve the doc

…tate` method.

Support PPR with negative angle Support Pass options for CLI

Updated changelog

dime10

Nice work!! :) So far I'm leaving some comments regarding organization, documentation, naming, etc. I will leave a second review regarding the C++ implementation tomorrow :)

doc/releases/changelog-dev.md

frontend/catalyst/passes/builtin_passes.py

mlir/include/QEC/Transforms/Passes.td

mlir/include/QEC/IR/QECDialect.td

dime10 · 2025-05-06T22:19:56Z

mlir/include/QEC/IR/QECDialect.td

+        Prepares logical qubits in a specific initial quantum state, 
+        such as |0⟩, |1⟩, |+⟩, |-⟩, |Y⟩, |-Y⟩, |m⟩, or |m̅⟩.
+
+        This operation is typically used at the start of a quantum circuit to initialize 


I wouldn't say this operation is used at the start of a circuit, don't we need this everywhere in order to implement pi/8 rotations?

Yes, we need this everywhere we decompose pi/8 rotations.

One more thing, in Catalyst, we assume that the qubits are prepared in |0>. So if the program starts from |+>, the developer needs to apply the H gate when writing in Pennylane. In QEC, I think the preparation step and applying the gate could be different in terms of performance. So, I'm thinking of letting users define the prepared state as well.

Do you plan on keeping this operation now that we have fabricate?

If yes, what are the semantics with respect to the input state? Does the prepare op require that the input is in a 0 state?

mlir/include/QEC/IR/QECDialect.td

Co-authored-by: David Ittah <[email protected]>

isaacdevlugt · 2025-05-07T21:43:48Z

doc/releases/changelog-dev.md

@@ -2,6 +2,20 @@

 <h3>New features since last release</h3>

+* A new compilation pass has been added to Catalyst to decompose Pauli product rotations (PPRs) into
+  Pauli product measurements (PPMs). Non-Clifford (pi/8) rotations require the consumption of a


Suggested change

Pauli product measurements (PPMs). Non-Clifford (pi/8) rotations require the consumption of a

Pauli product measurements (PPMs). Non-Clifford rotations, :math:`\exp(i\sigma_{x, y, y} \tfrac{\pi}{8})`, require the consumption of a

x, y, z?

The expression is also missing an indication that the exponential argument is a product.

I don't know that these rendered forms add that much, unless we say we have to define the term PPR mathematically whenever we use it. It's also harder to read unrendered.

I think we should do something to clarify what the "pi/8" means, especially because, in PL, we take the convention of the factor of 1/2 being in the exponent already! I found that to be a pesky blocker when trying to roughly implement some things in the paper in PL.

How about defining PPR once when it is first mentioned? Then you can say Non-Clifford (Θ=pi/8) rotations assuming theta was the variable used in the definition

isaacdevlugt · 2025-05-07T21:44:02Z

doc/releases/changelog-dev.md

@@ -2,6 +2,20 @@

 <h3>New features since last release</h3>

+* A new compilation pass has been added to Catalyst to decompose Pauli product rotations (PPRs) into
+  Pauli product measurements (PPMs). Non-Clifford (pi/8) rotations require the consumption of a
+  magic state, while Clifford rotations will not. The methods are implemented as described in


Suggested change

magic state, while Clifford rotations will not. The methods are implemented as described in

magic state, while Clifford rotations, :math:`\exp(i\sigma_{x, y, y} \tfrac{\pi}{4})`, will not. The methods are implemented as described in

doc/releases/changelog-dev.md

isaacdevlugt · 2025-05-07T22:00:55Z

frontend/catalyst/passes/builtin_passes.py

+    PPRs (pi/8) are decomposed first, and then Clifford PPRs (pi/4) are decomposed. Non-Clifford
+    decomposition can be performed in one of two ways: "clifford-corrected" or "auto-corrected",


See changelog entry suggestion. I'd do the same here!

frontend/catalyst/passes/builtin_passes.py

- Updated docstring - Renamed variable name

Co-authored-by: Isaac De Vlugt <[email protected]> Update doc/releases/changelog-dev.md Co-authored-by: Isaac De Vlugt <[email protected]>

clean format

frontend/catalyst/passes/builtin_passes.py

…ethods

- Applied `qec.fabricate` in DecomposeCliffordPPR - Improved code

dime10

Nice work @sengthai 🎉 🎉

This is looking great, only a few points we could improve on :)

dime10 · 2025-05-12T19:51:49Z

frontend/test/pytest/test_peephole_optimizations.py

+#
+# commute_ppr
+#


Here as well I would avoid these comments, you should use docstrings to document individual tests, and classes to group similar tests together. That's how we organize all our other pytests as well :)

In this case the headers don't really do much anyway since they just repeat the name of the test function.

dime10 · 2025-05-12T19:52:42Z

frontend/test/pytest/test_peephole_optimizations.py

+
+def test_commute_ppr():
+    """
+    Test commute_ppr


A good docstring will say what you are testing and possibly additional information like what you are expecting (if that isn't obvious).

dime10 · 2025-05-12T19:55:31Z

mlir/include/QEC/IR/QECDialect.td

+        Prepares logical qubits in a specific initial quantum state, 
+        such as |0⟩, |1⟩, |+⟩, |-⟩, |Y⟩, |-Y⟩, |m⟩, or |m̅⟩.
+
+        This operation is typically used at the start of a quantum circuit to initialize 


Do you plan on keeping this operation now that we have fabricate?

If yes, what are the semantics with respect to the input state? Does the prepare op require that the input is in a 0 state?

dime10 · 2025-05-12T20:00:09Z

mlir/include/QEC/IR/QECDialect.td

+        I1:$condition,  // The condition qubit
+        PauliWord:$pauli_product,
+        PauliWord:$else_pauli_product,


I would reorder these slightly, instead of framing it as an if-else with a condition, framing it as a switch (or selector) where the provided switch value simply indexes the provided pauli products makes more sense to me, because:

it is easily extensible to more products with a larger integer

it fits the select.ppm name better

Suggested change

I1:$condition, // The condition qubit

PauliWord:$pauli_product,

PauliWord:$else_pauli_product,

I1:$switch,

PauliWord:$pauli_product_0,

PauliWord:$pauli_product_1,

dime10 · 2025-05-12T20:02:58Z

mlir/lib/QEC/Transforms/DecomposeCliffordPPR.cpp

+/// ─────┌───┐───────
+/// ─────│ P │(π/4)──
+/// ─────└───┘───────
+///
+/// into
+///
+/// ─────┌───┐────────┌───────┐──
+/// ─────|-P |────────| P(π/2)|──
+/// ─────|   |────────└───╦───┘──
+///      |   ╠════════════╣
+///      |   |     ┌───┐  ║
+/// |0⟩──| Y |─────| X ╠══╝
+///      └───┘     └───┘


Wow these are nice drawings 😄

dime10 · 2025-05-12T21:03:23Z

mlir/lib/QEC/Transforms/DecomposeCliffordPPR.cpp

+        rewriter.create<PPRotationOp>(loc, pauliP, PI_DENOMINATOR, outPZQubits, cond.getResult());
+
+    rewriter.replaceOp(op, pprPI2.getOutQubits());
+    return pprPI2;


Should we not destroy the ancilla before returning?

I was thinking it might be helpful to add single qubit allocation/deallocation ops to not have to deal with the register unless necessary, what do you think?

What I've also seen, which would work here, is a destructive measurement (that automatically deallocates the qubit).

dime10 · 2025-05-12T21:08:14Z

mlir/lib/QEC/Utils/Utility.cpp

+namespace catalyst {
+namespace qec {
+
+AllocOp buildAllocQreg(Location loc, int64_t size, PatternRewriter &rewriter)


It looks like these should be builders on the operations directly no?

dime10 · 2025-05-12T21:09:00Z

mlir/lib/QEC/Utils/Utility.cpp

+    return rewriter.create<ExtractOp>(loc, type, qreg, nullptr, idxAttr);
+}
+
+LogicalInitKind getMagicState(QECOpInterface op)


Should this method be part of the interface then?

dime10 · 2025-05-12T21:10:45Z

mlir/lib/QEC/Utils/Utility.cpp

Generally speaking, "utility" modules often hint at insufficient or poorly designed apis. Not that they never have their place, but like in this case, the functionality is often better placed directly with the relevant code constructs (classes, modules, etc).

dime10 · 2025-05-12T21:14:08Z

mlir/lib/QEC/Transforms/DecomposeNonCliffordPPR.cpp

+    auto loc = op.getLoc();
+
+    // Prepare |0⟩ and |m⟩
+    auto zero = rewriter.create<FabricateOp>(loc, LogicalInitKind::zero);


Similar from the other file, it might be nice to distinguish between using a factory vs regular ancilla allocation.

And same comments regarding the deallocation of ancilla qubits.

sengthai added 5 commits April 16, 2025 18:04

Add the qec.prepare operation for initializing the logical qubits.

dd110d1

- Introduced SelectPPMeasurementOp for conditional Pauli product me…

907957d

…asurements based on a boolean control. - Added convenience builders. - Improve the doc

Add convenience builder

9de681b

Implement new pass that includes auto-corrected and `inject-magic-s…

a37ab39

…tate` method.

Added test case

dc78cfb

Support PPR with negative angle Support Pass options for CLI

sengthai marked this pull request as ready for review April 24, 2025 12:57

sengthai changed the title ~~[WIP] Implement a decomposition of non-Clifford PPRs into PPMs~~ Implement a decomposition of non-Clifford PPRs into PPMs Apr 24, 2025

sengthai requested a review from a team April 24, 2025 12:57

Refactor decomposition method

57e1276

sengthai added enhancement New feature or request do-not-merge labels Apr 24, 2025

This comment was marked as resolved.

Sign in to view

Fixed memory buffer caused by using ArrayRef

6aa10bf

This comment was marked as outdated.

Sign in to view

sengthai added 4 commits April 24, 2025 17:58

Added verifier to

0994d63

Supported decomposition of

3bd3292

Merge branch 'main' into ppr-to-ppm

a26289b

Supported pass in frontend

44c7f90

Updated changelog

sengthai removed the do-not-merge label Apr 28, 2025

sengthai added 3 commits April 29, 2025 10:59

Add tests

d2c2e26

Separate decomposition of pi/4 and pi/8 PPR into two MLIR passes

2fb6a99

codefactor

d23eddd

sengthai changed the title ~~Implement a decomposition of non-Clifford PPRs into PPMs~~ Implement a decomposition of PPRs into PPMs Apr 29, 2025

sengthai added 3 commits April 30, 2025 09:47

Updated test in

9b84432

Formated

914843a

Added test case

a5a55bd

dime10 self-requested a review May 1, 2025 22:17

dime10 requested changes May 6, 2025

View reviewed changes

sengthai and others added 2 commits May 7, 2025 10:45

Apply suggestions from code review

055681c

Co-authored-by: David Ittah <[email protected]>

Update docstring

f663816

Co-authored-by: David Ittah <[email protected]>

isaacdevlugt requested changes May 7, 2025

View reviewed changes

sengthai and others added 2 commits May 8, 2025 10:55

- Modified state-prep to avoid-y-measure

6191c9c

- Updated docstring - Renamed variable name

Update frontend/catalyst/passes/builtin_passes.py

1b917e6

Co-authored-by: Isaac De Vlugt <[email protected]> Update doc/releases/changelog-dev.md Co-authored-by: Isaac De Vlugt <[email protected]>

sengthai force-pushed the ppr-to-ppm branch from 74a62a1 to 1b917e6 Compare May 8, 2025 15:15

sengthai added 2 commits May 8, 2025 11:41

Added more info on

a511f45

clean format

Removed function call in pytest

e3874c2

dime10 reviewed May 8, 2025

View reviewed changes

frontend/catalyst/passes/builtin_passes.py Outdated Show resolved Hide resolved

sengthai added 3 commits May 8, 2025 15:58

Update docstring for ppr_to_ppm function to clarify decomposition m…

7521430

…ethods

- Added qec.fabricate to QEC dialect

3beb2f3

- Applied `qec.fabricate` in DecomposeCliffordPPR - Improved code

Supported qec.fabricate in decompose_non_clifford_ppr

fb28104

dime10 requested changes May 12, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement a decomposition of PPRs into PPMs #1664

Implement a decomposition of PPRs into PPMs #1664

sengthai commented Apr 16, 2025 •

edited

Loading

This comment was marked as resolved.

This comment was marked as outdated.

dime10 left a comment

dime10 May 6, 2025

sengthai May 8, 2025

sengthai May 8, 2025

dime10 May 12, 2025 •

edited

Loading

isaacdevlugt May 7, 2025

dime10 May 7, 2025 •

edited

Loading

dime10 May 7, 2025 •

edited

Loading

isaacdevlugt May 8, 2025

dime10 May 8, 2025 •

edited

Loading

isaacdevlugt May 7, 2025

isaacdevlugt May 7, 2025

dime10 left a comment

dime10 May 12, 2025 •

edited

Loading

dime10 May 12, 2025

dime10 May 12, 2025 •

edited

Loading

dime10 May 12, 2025

dime10 May 12, 2025

dime10 May 12, 2025

dime10 May 12, 2025

dime10 May 12, 2025

dime10 May 12, 2025

dime10 May 12, 2025

	Pauli product measurements (PPMs). Non-Clifford (pi/8) rotations require the consumption of a
	Pauli product measurements (PPMs). Non-Clifford rotations, :math:`\exp(i\sigma_{x, y, y} \tfrac{\pi}{8})`, require the consumption of a

	magic state, while Clifford rotations will not. The methods are implemented as described in
	magic state, while Clifford rotations, :math:`\exp(i\sigma_{x, y, y} \tfrac{\pi}{4})`, will not. The methods are implemented as described in

		PPRs (pi/8) are decomposed first, and then Clifford PPRs (pi/4) are decomposed. Non-Clifford
		decomposition can be performed in one of two ways: "clifford-corrected" or "auto-corrected",

Implement a decomposition of PPRs into PPMs #1664

Are you sure you want to change the base?

Implement a decomposition of PPRs into PPMs #1664

Conversation

sengthai commented Apr 16, 2025 • edited Loading

This comment was marked as resolved.

This comment was marked as outdated.

dime10 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dime10 May 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dime10 May 7, 2025 • edited Loading

Choose a reason for hiding this comment

dime10 May 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dime10 May 8, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dime10 left a comment

Choose a reason for hiding this comment

dime10 May 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dime10 May 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sengthai commented Apr 16, 2025 •

edited

Loading

dime10 May 12, 2025 •

edited

Loading

dime10 May 7, 2025 •

edited

Loading

dime10 May 7, 2025 •

edited

Loading

dime10 May 8, 2025 •

edited

Loading

dime10 May 12, 2025 •

edited

Loading

dime10 May 12, 2025 •

edited

Loading