RFC: tracking new squin statements

[david-pl]

We repeatedly run into issues where a new squin statement is added to the dialect without adding all the corresponding implementations in all method tables / rewrites. From a user perspective, I'd expect that any statement available in a dialect works in all places.

@cduck proposed to add a unit test. For example, we could have a kernel that needs to include every single dialect statement (checked by looping over all available statements and checking). Then, we can run this kernel through all required implementations and check the result.
The only disadvantage of this is that it may block PRs that add new statements. Then again, I think this is the only sure-fire way to avoid missing implementations.

We'll also need a list of all the places we need to run the kernel through. Right now, I can think of the following:

• Noise to StochasticUnitary rewrite rule
• PyQrack simulation
• cirq emit
• SquinToStimPass
• Address analysis

@johnzl-777 @kaihsin @weinbe58 any other places? I suppose there are some things that need to be tested downstream as well, but this can't be included here.

[johnzl-777]

@cduck proposed to add a unit test. For example, we could have a kernel that needs to include every single dialect statement (checked by looping over all available statements and checking).

Just to be precise here, you mean that the kernel would be created by hand but then there would be a way to check that kernel contains every possible squin statement, right?

Then, we can run this kernel through all required implementations and check the result. The only disadvantage of this is that it may block PRs that add new statements. Then again, I think this is the only sure-fire way to avoid missing implementations.

I think it's probably a good thing to have some (more) "mechanical"/"code" level friction on top of the human element (RFCs and triage if things become contested) (:

If we're forced to add logic to method tables/rewrites for new statements we can find out sooner rather than later if it proves to be particularly clunky/not worth it.

We'll also need a list of all the places we need to run the kernel through. Right now, I can think of the following:

* Noise to `StochasticUnitary` rewrite rule

* PyQrack simulation

* cirq emit

* `SquinToStimPass`

* Address analysis

@johnzl-777 @kaihsin @weinbe58 any other places? I suppose there are some things that need to be tested downstream as well, but this can't be included here.

MeasurementIDAnalysis and Site analysis come to mind (: @weinbe58 a bit of a tangent but is it still the case that AddressAnalysis and NSitesAnalysis are redundant? I know the semantics for broadcast and apply have flip-flopped but if we're getting to the point where we have to start enforcing method table support through something like this RFC then I think it's definitely worth cutting down on any unnecessary analyses

[david-pl]

Just to be precise here, you mean that the kernel would be created by hand but then there would be a way to check that kernel contains every possible squin statement, right?

@johnzl-777 yes, that's also what I did in the draft PR #436
You can't really autogenerate the kernel since the arguments of the statements vary. However, you can easily check if all statements are there.

I'll look into Site and MeasurementID analysis.

[weinbe58]

MeasurementIDAnalysis and Site analysis come to mind (: @weinbe58 a bit of a tangent but is it still the case that AddressAnalysis and NSitesAnalysis are redundant? I know the semantics for broadcast and apply have flip-flopped but if we're getting to the point where we have to start enforcing method table support through something like this RFC then I think it's definitely worth cutting down on any unnecessary analyses

@johnzl-777 no they are not redundant the issue was related Apply and Broadcast having the same signature but different semantics.

[jon-wurtz]

I wonder if this can be made into a Kirin issue-- this sort of self-consistency extends to all dialect groups, not just squin, so having a dialect validation function (metacompiler? idk) could be used in all sorts of places. Or even as a CI/CD test

[david-pl]

@jon-wurtz I was thinking the same. However, I'm not sure what can be done there since method tables may (and sometimes have to) be defined in other places / packages as the dialect. Also, beyond going "this statement has a method in this table" you might not be able to check much. The tests suggested here are somewhat more specific, so even with a generic way to check the methods in kirin, we still need them here.

I'll file an upstream issue.

Edit: one more thing, I forgot to mention: the tests proposed here also include different rewrites. I don't think it's generally possible to check those, i.e. as developer you have to check whether the application of a specific rewrite rule to a statement gives the correct result. There's no way around that.