Conversation
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
| add_custom_command( | ||
| TARGET mlir-doc | ||
| POST_BUILD | ||
| COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/docs/ | ||
| ${CMAKE_CURRENT_SOURCE_DIR}/docs/mlir/ | ||
| COMMAND ${CMAKE_COMMAND} -D DOCS_DIR:PATH=${CMAKE_CURRENT_SOURCE_DIR}/docs/mlir -P | ||
| ${CMAKE_CURRENT_SOURCE_DIR}/cmake/CleanMLIRDocs.cmake | ||
| COMMENT "Copying and cleaning up generated MLIR documentation" | ||
| VERBATIM) |
There was a problem hiding this comment.
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. 🤔
There was a problem hiding this comment.
I haven't quite managed to work around this for now. Will have to reinvestigate at a later point.
|
A brief overview of everything that remains open: Main FunctionI 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 OperationsThe following QC operations can currently not be converted to Jeff because they do not have a direct counterpart:
Unconvertible Jeff OperationsThe following Jeff operations can currently not be converted to QC because they do not have a direct counterpart:
In addition, the following additional conversions are not implemented yet, as I believe their implementation needs further discussion:
TestsThe current version of the tests does not perform proper equivalence checking but relies on (very minimal) string comparisons. |
|
I'll try to collect my thoughts here as well so that there is some kind of record of them.
I think going from MQT -> Jeff should not be particularly hard, as we have a much simpler setup in general (at least for now).
Based on the discussions in unitaryfoundation/jeff#38,
Based on the discussions in unitaryfoundation/jeff#38,
Based on the discussions in unitaryfoundation/jeff#38,
Based on the discussions in unitaryfoundation/jeff#38, these should be converted to Pauli Rotations.
Based on the discussions in unitaryfoundation/jeff#38, these should be converted to custom gates.
While not explicitly mentioned in unitaryfoundation/jeff#38, I believe a
Based on the semantic description, I would argue that our
Based on the semantics in the spec, I would argue that
These will be a little trickier to support.
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.
This very much depends on how we decide to handle registers. Hopefully, we can resolve this soon.
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.
I would guess that roundtrip tests could be pretty effective here at catching issues. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
2 participants
Description
This PR adds conversions for the Jeff dialect.
Related to #1196
Checklist: