✨ Add conversions for Jeff dialect

[denialhaag]

Description

This PR adds conversions for the Jeff dialect.

Related to #1196

Checklist:

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[denialhaag]

Two problems I have stumbled across so far:

[denialhaag]

This currently makes the configuration fail. I don't exactly understand what's going on, but it looks like the mlir-doc target is also being created by jeff-mlir, leading to interference.

Another problem seems to be that calling mlir-doc also triggers the generation of the Jeff documentation in the _deps directory.

Maybe it's possible to add flags to jeff-mlir to toggle the documentation generation. 🤔

[burgholzer]

I haven't quite managed to work around this for now. Will have to reinvestigate at a later point.

[denialhaag]

A brief overview of everything that remains open:

Main Function

I have not yet looked into the proper conversion of a QC-style main function to a Jeff-style main function. The current implementation of the tests relies on bare-bones modules without a properly defined entry point. This might require some coordination with Xanadu, as we should align on what a Jeff-style main function exactly looks like. That said, the implementation of the conversion itself should be straightforward.

Unconvertible QC Operations

The following QC operations can currently not be converted to Jeff because they do not have a direct counterpart:

• SXOp and SXdgOp
• ROp and U2Op
• iSWAPOp, DCXOp, and ECROp
• RXXOp, RYYOp, RZXOp, and RZZOp
• XXPlusYYOp and XXMinusYYOp
• BarrierOp

Unconvertible Jeff Operations

The following Jeff operations can currently not be converted to QC because they do not have a direct counterpart:

• QubitFreeZeroOp (we can convert QubitFreeOps)
• QubitMeasureOp (we can convert QubitMeasureNDOps)
• PPROp and CustomOp
• Everything related to quantum registers

In addition, the following additional conversions are not implemented yet, as I believe their implementation needs further discussion:

• All numerical operations
• All SCF operations

Tests

The current version of the tests does not perform proper equivalence checking but relies on (very minimal) string comparisons.

[burgholzer]

I'll try to collect my thoughts here as well so that there is some kind of record of them.

A brief overview of everything that remains open:

Main Function

I have not yet looked into the proper conversion of a QC-style main function to a Jeff-style main function. The current implementation of the tests relies on bare-bones modules without a properly defined entry point. This might require some coordination with Xanadu, as we should align on what a Jeff-style main function exactly looks like. That said, the implementation of the conversion itself should be straightforward.

I think going from MQT -> Jeff should not be particularly hard, as we have a much simpler setup in general (at least for now).
The reverse direction (Jeff -> MQT) seems slightly more complicated, even though it should also not be too hard. Either we need to do some matching on the entry point function or we need to slightly rethink how we handle the main boilerplate code in the MQT (which is definitely not set in stone yet).

Unconvertible QC Operations

The following QC operations can currently not be converted to Jeff because they do not have a direct counterpart:

• SXOp and SXdgOp

Based on the discussions in unitaryfoundation/jeff#38, SX will probably be added as a dedicated operation. SXdgOp will then simply be adj @ SX.

• ROp and U2Op

Based on the discussions in unitaryfoundation/jeff#38, ROp is still up for debate, while U2 should be treated as a special case of U3 in both conversion directions, i.e., it should be translated to U3 when going to Jeff and coming from Jeff, the specialization is probably handled through our UOp canonicalizations.

• iSWAPOp, DCXOp, and ECROp

Based on the discussions in unitaryfoundation/jeff#38, iSWAP will probably be added directly while the other two shall simply be exported as custom gates.

• RXXOp, RYYOp, RZXOp, and RZZOp

Based on the discussions in unitaryfoundation/jeff#38, these should be converted to Pauli Rotations.

• XXPlusYYOp and XXMinusYYOp

Based on the discussions in unitaryfoundation/jeff#38, these should be converted to custom gates.

• BarrierOp

While not explicitly mentioned in unitaryfoundation/jeff#38, I believe a custom gate would be fine for this.

Unconvertible Jeff Operations

The following Jeff operations can currently not be converted to QC because they do not have a direct counterpart:

• QubitFreeZeroOp (we can convert QubitFreeOps)

Based on the semantic description, I would argue that our dealloc is actually closer to QubitFreeZeroOp, while QubitFreeOp would be converted to reset -> dealloc.

• QubitMeasureOp (we can convert QubitMeasureNDOps)

Based on the semantics in the spec, I would argue that QubitMeasureOp is equivalent to our measure -> dealloc.

• PPROp and CustomOp

These will be a little trickier to support.
What should be moderately easy is to support specializations of PPROp, namely

• rx, ry, rz
• rxx, ryy, rzz, rzx

Given how prevalent these PPRs are in FTQC literature, we may sooner or later add this as a dedicated primitive to our supported gates. For now, we may convert the specializations but may fail the conversions for general rotations.

As for custom gates, what we could do here is to support matching the names of gates that we could not explicitly export as well known gates (xx_plus_yy, ecr, etc.) so that a roundtrip of all MQT gates would work.

• Everything related to quantum registers

This very much depends on how we decide to handle registers. Hopefully, we can resolve this soon.

In addition, the following additional conversions are not implemented yet, as I believe their implementation needs further discussion:

• All numerical operations
• All SCF operations

As discussed offline, these conversion patterns could become part of the Jeff-mlir repository itself. It may be worth opening an issue about that over there.
At least for the numeric operations, I could see this working out nicely.
For the SCF ones, it may depend on how we decide to handle these in our dialects.

Tests

The current version of the tests does not perform proper equivalence checking but relies on (very minimal) string comparisons.

I would guess that roundtrip tests could be pretty effective here at catching issues.

[denialhaag]

@burgholzer, I just wanted to confirm that I'm applying the new test infrastructure correctly. Two questions:

1. Is JeffRoundTrip/Operations/StandardGates/HOp.cpp correct? If it's meant to refer to a file, that file, of course, wouldn't exist.
2. Is the instantiation name meant to be QCHopTest here? In principle, this does make sense to me, as the test starts with a qc.h operation.

I have adapted this from here:

core/mlir/unittests/Conversion/QCToQCO/test_qc_to_qco.cpp

Lines 176 to 179 in d9209b7

	/// \name QCToQCO/Operations/StandardGates/HOp.cpp
	/// @{
	INSTANTIATE_TEST_SUITE_P(
	QCHOpTest, QCToQCOTest,

[burgholzer]

I think this is generally a consequence of an earlier design in the test PR where I had all of these split into separate files. That led to crazy long compile times though, so I combined everything back into one.
I still wanted to somehow have separators between the individual tests. What you linked is the end result of that.
It's definitely not perfect, so we can happily adjust it. I just want a way to separate the individual test groups and have something to easily search for in the file.
Best case, we would not even do round trip tests here, but would have the jeff Builder and verify both conversions similarly to how we verify QC<->QCO.
Probably the round trip tests do not hurt though and I think the current structure should be fine.
Feel free to tweak the names of the tests. (Shouldn't this be QCO for example, and shouldn't it be HOp?)

Does any of that make sense?

[denialhaag]

I think this is generally a consequence of an earlier design in the test PR where I had all of these split into separate files. That led to crazy long compile times though, so I combined everything back into one.
I still wanted to somehow have separators between the individual tests. What you linked is the end result of that.

Okay, that makes perfect sense to me!

Best case, we would not even do round trip tests here, but would have the jeff Builder and verify both conversions similarly to how we verify QC<->QCO.

Agreed. I'd see the current round-trip-only tests as a temporary solution until we have a Jeff builder.

Shouldn't this be QCO for example, and shouldn't it be HOp?

At this very moment, the conversion is still between QC and Jeff, but I'll change this tomorrow! I wanted to put the testing on a more solid footing first. If I'm not mistaken, updating the tests after the change should be very straightforward now (basically, search and replace QC with QCO).