🚸 MLIR - Define custom builders

[denialhaag]

Problem Statement

Currently, creating an operation in C++ is more cumbersome than it needs to be. It would be nice if some operations had custom builders that reduce boilerplate code.

Proposed Solution

Wherever it makes sense, custom builders should be defined. The C++ code should be updated to use these new builders.

[DRovara]

Some potential for custom builders (these are just suggestions, they are not all desperately necessary):

• Gates without controls
• Gates with only controls/targets
• Gates without parameters

I'm also not sure if this makes sense but maybe we can predefine the output types (e.g. the QubitType for gate targets) in builders as well so we don't have to specify them when constructing new operations. After all, we know that the types will always be fixed.

[burgholzer]

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.

[burgholzer]

One of the past PRs introduced InferTypeOpInterface, which automatically added convenient builders to some of the classes in our dialects. As a result, this issue might boil down to replacing the actual locations where the builders are invoked to use the more convenient builders with the type inference. Maybe type inference can also be added to more of our types. There seems to be no need for explicitly defining builders ourselves to accomplish this.

[taminob]

While working on #1207, I wanted to create an XOp in C++. This currently requires specifying out_qubits_type, pos_ctrl_out_qubits_type, neg_ctrl_out_qubits_type, static_params, params_mask, params, in_qubits, pos_ctrl_in_qubits, neg_ctrl_in_qubits which can be cumbersome, especially because the output types can be inferred from the input qubit ranges.

There are also easier build() methods simply accepting a single value range for the result types or also one simply accepting operand and result type ranges, but these overloads require explicitly stating the operand and result segment sizes to differentiate between the three segments (failure to do so will result in e.g. error: 'mqtopt.x' op result count (2) does not match with the total size (0) specified in attribute 'resultSegmentSizes'.

Overall, there should be a constructor which allows to omit all optional values (static_params and params_mask) and also infer the output types. It might also be nice-to-have to allow the omission of params, although this might mess with overload resultion since it's the same type as the other operands (I don't know if there are XOps which can also accept parameters).

[taminob]

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 I mentioned above (documentation). I think the NoParameter would probably directly imply SameOperandsAndResultType, right? Might be relatively easy to integrate by using the third parameter of ParamNativeOpTrait to inject the additional trait for NoParameter.

It's another topic, but looking into these traits in general could be helpful (although the documentation is pretty sparse). E.g. Commutative could also allow us to use some standard optimizations of LLVM (maybe)?

[burgholzer]

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 I mentioned above (documentation). I think the NoParameter would probably directly imply SameOperandsAndResultType, right? Might be relatively easy to integrate by using the third parameter of ParamNativeOpTrait to inject the additional trait for NoParameter.

I believe this should be true, i.e., NoParameter should imply that trait. Definitely worth exploring.

It's another topic, but looking into these traits in general could be helpful (although the documentation is pretty sparse). E.g. Commutative could also allow us to use some standard optimizations of LLVM (maybe)?

I very much agree. We should leverage existing infrastructure as much as possible.
I am currently trying to find some time to investigate the basic setup of our quantum dialects a little bit more so that we could, potentially, put them on a little more stable basis.
I'll probably have some more thoughts on this after you are back from your vacation.