Lukas Burgholzer

Hm.. I am pretty sure this is due to the gcc version being too old on these runners..

> I am aware of the code duplicates between the NA and SC device originating from a lot of copy paste. This PR is meant to provide a first initial...

> While working on this PR, it might also an idea to move the NA QDMI device to the QDMI directory, @burgholzer ? Should I open an issue for that...

Yeah, we should definitely try to avoid making it harder for optimizations. I have spent some time reading further on how the concept of modifiers could be realized and most...

The only problem with that is that, at least in MQT Core, a compound operation is not necessarily unitary as it might contain Measurements, Resets, or classically-controlled operations. And I...

Predefining the output types makes a lot of sense. It's a bit more code in the dialect definition but saves a lot of boilerplate code in the transformations and conversions.

One of the past PRs introduced [InferTypeOpInterface](https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Interfaces/InferTypeOpInterface.td), which automatically added convenient builders to some of the classes in our dialects. As a result, this issue might boil down to replacing...

> I just came across some pre-defined tablegen traits defined by MLIR which pretty much do exactly this. Especially `SameOperandsAndResultType` will automatically do the type inference for the result that...

Hey @flowerthrower and @taminob 👋🏼 Just wanted to throw another resource into the mix: [🔗 MQT Core CircuitOptimizer](https://github.com/munich-quantum-toolkit/core/blob/main/include/mqt-core/circuit_optimizer/CircuitOptimizer.hpp) We already implement several optimization passes in MQT Core as part of...

Just from past experience, the easiest passes to accommodate are the gate cancellation and gate merging passes. Maybe a good first start would be to look into the MLIR passes...