MLIR Conversion(s)

[flowerthrower]

Description

This PR originates from this mqt-mlir PR and introduces conversions between Catalysts quantum dialect and the MQTOpt dialect.

Checklist:

• The pull request only contains commits that are related to it.
• I have added appropriate tests and documentation.
• I have made sure that all CI jobs on GitHub pass.
• The pull request introduces no new warnings and follows the project's style guidelines.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[burgholzer]

Now that #879 is merged, this needs to be rebased

[burgholzer]

Thanks @flowerthrower for your tireless work on this!
I still haven't managed to fully review the actual conversion passes, but made another detailed pass on the infrastructure surrounding the conversions.

Most of the feedback is inline already.
The main reason for clang-tidy to report somewhat bogus results is that it simply cannot find the catalyst headers, so it gets confused.
This also points to one of the things, that is not an inline comment: We really want to be testing this integration in CI with an appropriate amount of tests.
The CI workflow should be set up to install Catalyst and successfully build the project. Otherwise, the confidence in the code working as expected will not be very high over time.
At some point, we want to distribute this integration to third parties, where this has to be seamless.

Ideally, we would add an optional python dependency group for catalyst, similar to qiskit (

core/pyproject.toml

Lines 49 to 51 in 79cb99f

	qiskit = [
	"qiskit[qasm3-import]>=1.0.0",
	]

) and would use Python whenever available to detect the installed version of Catalyst or to point find_package to the right direction. We do something pretty similar for mqt-core and pybind11 in most of our projects: https://github.com/cda-tum/mqt-qcec/blob/aa833928fcd47ee132075e90a301aa0277e7f476/cmake/ExternalDependencies.cmake#L6-L33

[burgholzer]

I am still trying to understand if this is a hard requirement.
I'd like to see this in action in CI and see how/if/when it fails.

[burgholzer]

I know this will probably be painfull to write, but can we please

• split these tests up so that they are more fine-granular and test more specific things
• explicitly test all supported operations as well as non-supported operations and their conversion.

https://github.com/munich-quantum-toolkit/core/blob/main/mlir/test/Dialect/MQTOpt/Transforms/consecutive-inverses.mlir is a good blueprint for more extensive tests at the moment.

If this is enough of a pain point to find a better way to test the infrastructure, then so be it.
We are adding quite some functionality here, so it should also be tested appropriately.
Most likely, we should be collecting coverage metrics for the MLIR part of the project. (this will have to wait for another PR though)

[ystade]

Just because I stumbe over it right now: Is this gymnastic with the version string necessary or can the VERSION_LESS operator of cmake be used directly? That might make the code cleaner here.

[burgholzer]

Seems reasonable to use VERSION_LESS 👍🏼

[burgholzer]

Just a couple of comments because the PR notifications where in my inbox 😌

[burgholzer]

fairly sure you need to use a different cache key here, otherwise there will be cache contention between the jobs.

Suggested change

	override_cache_key: c++-tests-mlir
	override_cache_key: c++-tests-mlir-catalyst

If we extend the matrix of CI workflows above, the cache key should also be updated.

[burgholzer]

This should not be necessary as you are running on macOS 14 already.

[burgholzer]

This should not be necessary as you are running on macOS 14 already.

[burgholzer]

Suggested change

	ninja -C catalyst/mlir/build MLIRQuantum
	cmake --build catalyst/mlir/build --target MLIRQuantum

[burgholzer]

Would be interesting to see this work on macos-13 (x86 runners) as well as llvm-version: 20.
The current build pipeline seems to pass, which is great already!

Unrelated to this PR in particular, but what could be a nice byproduct in a separate PR is that this already represents a functional macOS-14 CI pipeline for MLIR, which would be part of #925.

[burgholzer]

This needs to fail hard if Catalyst cannot be found.

Suggested change

	if(Catalyst_DIR)
	list(APPEND CMAKE_PREFIX_PATH "${Catalyst_DIR}")
	find_package(Catalyst REQUIRED)
	else()
	message(STATUS "Could not detect Catalyst CMake directory")
	endif()
	find_package(Catalyst REQUIRED)

[burgholzer]

Once a compatible version of Catalyst is released, this will probably also require a version specifier to indicate the minimum version required.

[burgholzer]

Ideally, there would be no need to do something like set(Catalyst_DIR "${Python_Catalyst_DIR}/..., but Catalyst_DIR would already be a result of the execute_process call.
Either catalyst provides an entry point for that (similar to pybind, nanobind, or mqt-core), or we parse this somewhat from output similar to the existing command here by a simple Python script.

[burgholzer]

Why was this commented out?

Suggested change

	# if(MLIR_VERSION VERSION_LESS MQT_MLIR_MIN_VERSION) message(FATAL_ERROR "MLIR version must be at
	# least ${MQT_MLIR_MIN_VERSION} but found ${MLIR_VERSION}") endif()
	if(MLIR_VERSION VERSION_LESS MQT_MLIR_MIN_VERSION)
	message(FATAL_ERROR "MLIR version must be at least ${MQT_MLIR_MIN_VERSION}")
	endif()