🐛 Replay cold-preview SWAP plan during hot routing

[simon1hofmann]

Description

Reverts the place logic introduced in #1997. Instead of only creating qco.static ops for materialized program qubits, all available hardware qubits are initialized. A subsequent canonicalization pass run will then remove unused static ops.

Checklist

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

If PR contains AI-assisted content:

• Any agent that created, edited, or submitted GitHub content was explicitly authorized for that scope, as required by our AI Usage Guidelines.
• Every agent-authored or agent-edited public text body begins with the visible disclosure 🤖 *AI text below* 🤖 (titles are exempt).
• I have disclosed AI assistance in the PR description.
• I confirm that I have personally reviewed and understood all AI-generated content, and accept full responsibility for it.

[simon1hofmann]

@MatthiasReumann As already talked about previously, I created a test case that was failing and a proposed fix. Would appreciate your feedback 🙏

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[MatthiasReumann]

Many thanks @simon1hofmann 🚀

I don't think this is quite right, yet. It is actually by design that the final forward Hot routes the program again. By doing so we can directly insert SWAPs into the IR without any replay mechanism.

The mapping pass works as follows

generateLayout:
[0]: (forward, backward)^{niterations} of route<Cold> using ntrials many initial random layouts. 
[1]: Find the "best" final layout which has been produced by the final *backward* iteration.

place:
[0]: Use this "best" layout to initially place the circuit 

route<Hot>: Final forward iteration while inserting SWAPs

I've pushed a few commits which (I think) will fix the bug also. Essentially, what I think is happening is that in insertSWAPs a SWAP wants to be inserted on an unmaterialized program qubit for which the infos weren't initialized.

@burgholzer FYI: I've removed the materializedPrograms for now. At some point, I want to get rid of the majority of the code in the place method anyway (inline extend the SCF ops while hot routing, for example) - so maybe let's revisit that idea again later and let the canonicalization pass remove unused static ops for now.

[simon1hofmann]

Many thanks @simon1hofmann 🚀

I don't think this is quite right, yet. It is actually by design that the final forward Hot routes the program again. By doing so we can directly insert SWAPs into the IR without any replay mechanism.

The mapping pass works as follows

generateLayout:
[0]: (forward, backward)^{niterations} of route<Cold> using ntrials many initial random layouts. 
[1]: Find the "best" final layout which has been produced by the final *backward* iteration.

place:
[0]: Use this "best" layout to initially place the circuit 

route<Hot>: Final forward iteration while inserting SWAPs

I've pushed a few commits which (I think) will fix the bug also. Essentially, what I think is happening is that in insertSWAPs a SWAP wants to be inserted on an unmaterialized program qubit for which the infos weren't initialized.

@burgholzer FYI: I've removed the materializedPrograms for now. At some point, I want to get rid of the majority of the code in the place method anyway (inline extend the SCF ops while hot routing, for example) - so maybe let's revisit that idea again later and let the canonicalization pass remove unused static ops for now.

Thanks a lot for the quick fix @MatthiasReumann 🙏

I reran the benchpress tests and your solutions seems to fix them as well 👍

[burgholzer]

Looks like a fine solution to me 👍🏻
Just spotted one potential typo. Then this can happily go in.

[burgholzer]

Ah also one more comment: do we really want to run a full canonicalization here or simply apply the specific pattern for removing static-sink pairs? Could be more efficient.

[MatthiasReumann]

Ah also one more comment: do we really want to run a full canonicalization here or simply apply the specific pattern for removing static-sink pairs? Could be more efficient.

Good idea! Done.