✨ Add absorb-swaps pass

[jmoosburger]

Description

• add new qco pass as warmup task (in cooperation with @MatthiasReumann)
• remove leading swap-gates in a circuit
• reorder static qubits instead

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:

• I have disclosed the use of AI tools in the PR description as per our AI Usage Guidelines.
• AI-assisted commits include an Assisted-by: [Model Name] via [Tool Name] footer.
• I confirm that I have personally reviewed and understood all AI-generated content, and accept full responsibility for it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[jmoosburger]

@MatthiasReumann

works fine now 💪
nice setup with the CMakePresets by the way... :)

i have another conceptional question though: which of the following circuits is correct?

circuit 120

q0 ----X---------- q1
       |
q1 ----X----X----- q2
            |
q2 ---------X----- q0

or:

circuit 201

q0 ----X---------- q2
       |
q1 ----X----X----- q0
            |
q2 ---------X----- q1

in my opinion its the second circuit 201, but the implementation we discussed produces the first result.
i just wanted to make sure that i'm correct in my assumption before i fix it :)

[jmoosburger]

the linter produces warnings on the one hand, but failes because of a http-error 403 (unauthorized) on the other hand. see here: https://github.com/munich-quantum-toolkit/core/actions/runs/26597942119/job/78373906843?pr=1750

is there anything i can do about it?

[denialhaag]

the linter produces warnings on the one hand, but failes because of a http-error 403 (unauthorized) on the other hand. see here: https://github.com/munich-quantum-toolkit/core/actions/runs/26597942119/job/78373906843?pr=1750

is there anything i can do about it?

Unfortunately, the action cannot post comments on PRs coming from a fork. 😕

That said, the report can also be found in the summary of the run: https://github.com/munich-quantum-toolkit/core/actions/runs/26597942119/attempts/1#summary-78373906843

[MatthiasReumann]

@jmoosburger

i have another conceptional question though: which of the following circuits is correct?

The best way to visualize this is to apply the SWAPs sequentially:

circuit 120

q0 ----X-- q1 ------------ q1
       |
q1 ----X-- q0 --X-- q2 --- q2
                |
q2 -------------X-- q0 --- q0

[jmoosburger]

the linter produces warnings on the one hand, but failes because of a http-error 403 (unauthorized) on the other hand. see here: https://github.com/munich-quantum-toolkit/core/actions/runs/26597942119/job/78373906843?pr=1750
is there anything i can do about it?

Unfortunately, the action cannot post comments on PRs coming from a fork. 😕

That said, the report can also be found in the summary of the run: https://github.com/munich-quantum-toolkit/core/actions/runs/26597942119/attempts/1#summary-78373906843

so if i resolve all the warnings the lint check will succeed, as it does not post a comment?

[MatthiasReumann]

so if i resolve all the warnings the lint check will succeed, as it does not post a comment?

If you resolve all warnings the CI / Lint / 🚨 Lint (pull request) workflow will succeed. The pull request will look like this one.

[jmoosburger]

so if i resolve all the warnings the lint check will succeed, as it does not post a comment?

If you resolve all warnings the CI / Lint / 🚨 Lint (pull request) workflow will succeed. The pull request will look like this one.

Which way is recommended?
the contribution.md suggests clang-tidy and the section Development Setup in installation.md suggests nox -s lint...

[denialhaag]

Which way is recommended? the contribution.md suggests clang-tidy and the section Development Setup in installation.md suggests nox -s lint...

nox -s lint lints everything but C++ files, so you would need to run clang-tidy locally. That said, I usually just use the error messages from the CI because clang-tidy might report different errors locally. 😬

[jmoosburger]

nox -s lint lints everything but C++ files, so you would need to run clang-tidy locally. That said, I usually just use the error messages from the CI because clang-tidy might report different errors locally. 😬

ahh, that explains a thing 👍
does the PR get squashed on merge then, right?

[denialhaag]

ahh, that explains a thing 👍 does the PR get squashed on merge then, right?

Yeah, we often squash, but it's not a must. Either way, we generally don't stress too much about having the perfect commit history in a PR.

[jmoosburger]

the linter suggests to pass a const reference in SwapAbsoption.findSwapsReadyForAbsorption():

Warning: the parameter 'wires' of type 'SmallVector' is copied for each invocation but only used as a const reference; consider making it a const reference

but this results in SegementationFaultExceptions ...
shall I rewrite the code or ignore the warning °^^

the other lint warnings are fixed 👍

[denialhaag]

the linter suggests to pass a const reference in SwapAbsoption.findSwapsReadyForAbsorption():

Warning: the parameter 'wires' of type 'SmallVector' is copied for each invocation but only used as a const reference; consider making it a const reference

but this results in SegementationFaultExceptions ... shall I rewrite the code or ignore the warning °^^

I tried around a bit locally and just pushed a potential fix. I think this was actually pointing to an issue. 🤔

Let me know if this looks good to you! 🙂

[jmoosburger]

I tried around a bit locally and just pushed a potential fix. I think this was actually pointing to an issue. 🤔

Let me know if this looks good to you! 🙂

fine with me 👍

do you have any other feedback, as this is pretty much what we've discussed on this feature?

[MatthiasReumann]

@jmoosburger If you think the pull request is ready to review, feel happy to request a review from someone (me) for on the top right of the pull request page.

[jmoosburger]

@jmoosburger If you think the pull request is ready to review, feel happy to request a review from someone (me) for on the top right of the pull request page.

Unfortunately i cannot edit the reviewers-section °^^

But i recognized, i need to add a summary and a description for the new pass first ☝️

[jmoosburger]

But i recognized, i need to add a summary and a description for the new pass first ☝️

I added a rather short description as i think it's not that complicated. feel free to share your personal opinion on that!

[MatthiasReumann]

It took us a pretty long time and three pull requests but we are finally here! Congratulations on your potentially first contribution to the MLIR compiler collection 🎉

I've left some small remarks which should be fairly easy to integrate. Otherwise, great job! 🚀

[jmoosburger]

It took us a pretty long time and three pull requests but we are finally here! Congratulations on your potentially first contribution to the MLIR compiler collection 🎉

I've left some small remarks which should be fairly easy to integrate. Otherwise, great job! 🚀

Thanks for your help and patience!
Hopefully there will be more in the future 🥳