Rewrite py.Mult to squin.Mult in squin kernel

[david-pl]

Seemed sufficiently different from #207, so I created a new branch for it.

@Roger-luo two things:

• I'm not sure whether this should be a Fixpoint.
• Should this also be part of the wire kernel?

[david-pl]

CI fails because of kirin v0.17.3 (passes locally with 0.17.2).

[david-pl]

Looks like CI failure is caused by this commit: QuEraComputing/kirin@9cb1f5d

The SimpleMergePolicy seems to rely on something being there that is already poped due to the change above.

[Roger-luo]

you don't need to use fixpoint here because the termination condition is simple here - you walk once, all py.binop.Mult is being replaced?

Also on 0.18 this will be simpler - we offer a dialect.canonicalize decorator so you can register the rule only without implementing this Pass. We can come back and cleanup this part after I finish the full refactor.

[Roger-luo]

The SimpleMergePolicy seems to rely on something being there that is already poped due to the change above.

@weinbe58 I'm wondering if you know what was causing the issue there? should we change the Walk order by changing the reverse option?

[Roger-luo]

Should this also be part of the wire kernel?

No, this is due to op dialect, so you only need one rule asscociate with op dialect.

[david-pl]

It was actually two issues, both of which you hinted at @Roger-luo :

• There are two type inference passes in the kernel: the second is apparently required because the desugaring pass messes up the types. I put the rewrite pass before the second inference pass, but it needed to be before the first. That fixed the inference.
• The typing of Scale was factor = info.argument(Complex), which didn't work properly since isinstance(2, complex) is False. I changed it to factor = info.argument(PyClass(numbers.Number)) and it works. Should this be added as a type upstream?

One more question:

No, this is due to op dialect, so you only need one rule asscociate with op dialect.

The op dialect doesn't have its own kernel. Should I create one just to add the rewriting pass there and then define both wired and kernel on top of it? How do I ensure the order with the type inference passes then?

Other than that: ready for review!

[weinbe58]

@weinbe58 I'm wondering if you know what was causing the issue there? should we change the Walk order by changing the reverse option?

This error is easily fixed in my pr #214 The heuristic noise model needs a big refactor to get it to work, unfortunately. I'll work on that today.

[david-pl]

Okay, so after rebasing the tests I added now fail due to kirin v0.17.3. Specifically, the type inference for Scale is again broken somehow. The change is once more the update to the worklist, i.e. this commit: QuEraComputing/kirin@9cb1f5d

The failing test checks to see if this kernel

@squin.kernel
def scale_mult():
    x = squin.op.x()
    y = squin.op.y()
    return 2 * (x * y)

gets rewritten such that it includes exactly one Scale and one Mult statement. Here are the IRs:

kirin v0.17.2:

scale_mult.print()
func.func scale_mult() -> !py.Op {
  ^0(%scale_mult_self):
  │ %x = squin.op.x() : !py.Op
  │ %y = squin.op.y() : !py.Op
  │ %0 = py.constant.constant 2 : !py.int
  │ %1 = squin.op.mult(lhs=%x, rhs=%y){is_unitary=False : !py.bool} : !py.Op
  │ %2 = squin.op.scale(op=%1, factor=%0){is_unitary=False : !py.bool} : !py.Op
  │      func.return %2
} // func.func scale_mult

kirin v0.17.3:

scale_mult.print()
func.func scale_mult() -> !py.int {
  ^0(%scale_mult_self):
  │ %x = squin.op.x() : !py.Op
  │ %y = squin.op.y() : !py.Op
  │ %0 = py.constant.constant 2 : !Bottom
  │ %1 = squin.op.mult(lhs=%x, rhs=%y){is_unitary=False : !py.bool} : !Bottom
  │ %2 = py.binop.mult(%0, %1) : !py.int
  │      func.return %2
} // func.func scale_mult

@Roger-luo do you have an idea what's going on here?

[david-pl]

CI passes on v0.17.4 of kirin. Just need to wait for the release to be available.

[Roger-luo]

hmm 0.17.4 does not fix it?

https://github.com/QuEraComputing/bloqade-circuit/actions/runs/14760201725/job/41438781218?pr=212#step:6:173

[david-pl]

@Roger-luo that's a different error though. The new tests pass, maybe I just need another rebase to main.