[MLIR] Provide convenience gate builders in tablegen

[paul0403]

Context:
There's many scheduled circuit transformation work at the mlir layer, like merge rotations and control flow related transforms, or even hardware gateset decomposition, where creating new gates will be necessary.

However, it came to our realization that currently the way to create a new gate in mlir (aka a quantum.custom operation) is more complicated than necessary, since all the fields need to be specified, even when the field values are empty. For example, see https://github.com/PennyLaneAI/catalyst/pull/1154/files#diff-bc5ebab69d5c90919840a29058595f8718f5e8a150e141f721250b76a0278f44R49

In light of this, we provide convenience builders in tablegen.

Description of the Change:
Provide convenience gate builders (aka builders for quantum.custom operations) in tablegen;
Create a tester pass -test-gate-buidler.

Benefits:
No need to specify a bunch of unnecessary boilerplate arguments when creating a new quantum.custom operation in a pass.
This can also be greatly beneficial for external contributors.

Possible Drawbacks:

Related GitHub Issues:

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.md on your branch with:

• A one-to-two sentence description of the change. You may include a small working example for new features.
• A link back to this PR.
• Your name (or GitHub username) in the contributors section.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.86%. Comparing base (3bea1b6) to head (e11923c).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1180   +/-   ##
=======================================
  Coverage   97.86%   97.86%           
=======================================
  Files          76       76           
  Lines       10819    10819           
  Branches     1283     1283           
=======================================
  Hits        10588    10588           
  Misses        179      179           
  Partials       52       52           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dime10]

Thanks for adding this!

[dime10]

We should give the same treatment to our other quantum gates :) (anything with control wires)

[paul0403]

I'm adding them.

[paul0403]

Done.

I am basing the category on whether the gate (a) has controls and (b) has parameters. This means there are 4 buidlers.

I think these sufficiently covers all the needs as of now.

[dime10]

I don't think we really want tests in the source directory 🤔

[paul0403]

The problem is, is there even another way to do mlir lit tests? The test directory is just a bunch of IR files.

[dime10]

What your asking for is C++ unit tests, unfortunately we don't have a framework setup for it yet, although Erick implemented one here: #1105 (just needs review)

[paul0403]

Wow, nice!

[paul0403]

Since all the arguments are wrapped in ValueRange(), thoughts about letting the helpers just take in a std::vector (or some other containers that can be implicitly passed via an initialization list), and converting them to ValueRange insider the helper?

[paul0403]

e.g.

void f(std::vector<int> v){
    for (int x : v){
        std::cout << x;
    }
}

int main() {
    f({10, 21, 44});
    return 0;
}

------
102144

[dime10]

We should avoid using vectors unless necessary. The mlir devs use specific data structures (like the ValueRange) in as many places as possible to avoid allocations, copies, etc.

[dime10]

I'm pretty sure you can pass a vector to a function expecting ValueRange though.

[dime10]

This mlir::ValueRange({inQubit, pz->getResult(0)}) is actually extremely dangerous though in a function call, because ValueRange is a non-owning object, your temporaries don't have a storage location for duration of the function call.