Stim REPEAT support

[johnzl-777]

This PR enables scf.For statements with the proper format to be represented as a Stim REPEAT statement. There can be no dependence on the iterator variable and the number of iterations must be known at the time of the rewrite.

Per feedback I received from the team presentation and some additional help from Phillip I’ve been able to eliminate the dependency on CSE ordering. CSE can now be invoked at any time in the pass with no impact on the correctness of the resulting program.

That being said, there are definitely areas I’d like to work on to expand the the supported semantics for QEC researchers.

1. There is a limitation on how far back you can index measurements that have occurred. This seems fine for something like a surface code memory experiment (which I have as a unit test) but becomes problematic for something like color code memory experiments where, in initialization, you have two sets of measurements that happen on the same qubits and then outside of the loop, you declare a time-based detector. That detector needs to access measurements that exceed the number of qubits being measured.

REPEAT 2 {
	MR 0 1 2
}
DETECTOR rec[-3] rec[-6] # you wouldn't be able to access this

I imagine if the number of iterations is propagated and perhaps some mechanism to accumulate measurements (say, py.binop.add with ilists) is carefully relaxed on invariance checking this could be supportable.

2. Potentially premature optimization but it might be more space efficient to have some lattice element that represents a RANGE of record indices. GetItem naturally complicates things but it would encourage a “lazier” growth of the GlobalRecordState than the current structure.

[codecov]

Codecov Report

❌ Patch coverage is 91.81495% with 46 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/bloqade/analysis/measure_id/impls.py	89.18%	16 Missing ⚠️
src/bloqade/stim/passes/flatten_except_loops.py	93.12%	9 Missing ⚠️
src/bloqade/analysis/measure_id/lattice.py	90.24%	4 Missing ⚠️
src/bloqade/stim/rewrite/set_detector_to_stim.py	81.81%	4 Missing ⚠️
src/bloqade/stim/dialects/cf/stmts.py	83.33%	3 Missing ⚠️
src/bloqade/stim/rewrite/scf_for_to_stim.py	90.32%	3 Missing ⚠️
src/bloqade/stim/rewrite/set_observable_to_stim.py	70.00%	3 Missing ⚠️
src/bloqade/stim/dialects/cf/emit.py	90.00%	2 Missing ⚠️
src/bloqade/stim/rewrite/squin_measure.py	85.71%	1 Missing ⚠️
src/bloqade/stim/rewrite/squin_noise.py	93.33%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[weinbe58]

I have some minor changes but overall it looks good! great job!

Note that it looks like this PR also closes #671

cc: @rafaelha

[weinbe58]

you should not need to copy the statements over you can first check that all uses of the body's block arguments are the Yield statement, if not you can give up on the rewrite, otherwise you can delete the yield statement then delete the block arguments in-place safely after.

[johnzl-777]

Wait, I don't think this can be the case though there's definitely uses of the block args beyond just the resulting yield.

The simplest counter example I can give is the repetition code structure test in test_scf_for_to_repeat.py, your block args get touched by other statements in the body (such as measure) and THEN get yielded.

[weinbe58]

This is OK for now but I think it would make sense to add more to the MeasureIDAnalysis to capture coordinates as well. That way we can just pull all this data from the analysis results instead of going through the IR and capturing the values manually from the IR which is more error prone.

[johnzl-777]

Done