✨ Add Additional Canonicalization Patterns for QTensor

[MatthiasReumann]

Description

This pull request adds two additional canonicalization patterns to the qtensor::InsertOp operation.

As discussed in #1718, in combination with the QuantumLoopUnroll pass, this should us allow to map any quantum program using scf.for operations to superconducting architectures that do not support backwards branching.

For example, base profile backends and adaptive profile backends without backwards branching support can run the following pass pipeline to map their quantum program.

--quantum-loop-unroll
  --cse
    --canonicalization
       --place-and-route

Changes

• ♻️ Use the TensorIterator for existing patterns in InsertOp.cpp
  • Can probably also be used for the logic implemented in ♻️ Implement Explicit Assumption Checks for Mapping Pass #1716
• Add RemoveExtractAfterInsertPattern and BubbleDownInsertPattern canonicalization patterns

Follow-Ups

• To map scf.for operations natively, implement an approximative algorithm to find a SWAP sequence that restores one layout to another.

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.

[burgholzer]

If I understood this correctly, then this complements the Extract-Insert canonicalization with an Insert-Extract one. Wouldn't that be better suited in the ExtractOp.cpp file?

Furthermore: Does the bubbling canonicalization provide any "real" advantage besides sorting? Both canonicalizations can handle tensor chains well already without it, right?

But I am most likely missing something 😌

[MatthiasReumann]

If I understood this correctly, then this complements the Extract-Insert canonicalization with an Insert-Extract one.

Roughly yes. However, where the Extract-Insert one removes "no-ops":

%q0_0, %t0_1 = extract %t0_0, 0
%t0_1 = insert %q0_0, %t0_1, 0

// transformed to 
// <empty>

the Insert-Extract removes double-extracts of the same index:

%q0_0, %t0_1 = extract %t0_0, 0
%q0_1 = qco.h %q0_0
%t0_1 = insert %q0_1, %t0_1, 0
%q0_2, %t0_2 = extract %t0_1, 0
%q0_3 = qco.x %q0_2
%t0_3 = insert %q0_3, %t0_2, 0

// transformed to 
%q0_0, %t0_1 = extract %t0_0, 0
%q0_1 = qco.h %q0_0
%q0_2 = qco.x %q0_1
%t0_2 = insert %q0_2, %t0_1, 0

Wouldn't that be better suited in the ExtractOp.cpp file?

This is probably true nonetheless. I was initially thinking about putting it to the AllocOp.cpp file since it affects the tensor "globally".

Both canonicalizations can handle tensor chains well already without it, right?

Yes.

Furthermore: Does the bubbling canonicalization provide any "real" advantage besides sorting?

I would argue the following (may be irrelevant or invalid)

• The pattern(s) provide(s) a canonical tensor chain (something which we can't do with qubits).
• Consequently, makes the mapping pass work after unrolling (or any other future transformation) with the assumptions made in ♻️ Implement Explicit Assumption Checks for Mapping Pass #1716.

Lastly, the pattern has been inspired by the -bubble-down-memory-space-casts pass.

[burgholzer]

If I understood this correctly, then this complements the Extract-Insert canonicalization with an Insert-Extract one.

Roughly yes. However, where the Extract-Insert one removes "no-ops":

%q0_0, %t0_1 = extract %t0_0, 0
%t0_1 = insert %q0_0, %t0_1, 0

// transformed to 
// <empty>

the Insert-Extract removes double-extracts of the same index:

%q0_0, %t0_1 = extract %t0_0, 0
%q0_1 = qco.h %q0_0
%t0_1 = insert %q0_1, %t0_1, 0
%q0_2, %t0_2 = extract %t0_1, 0
%q0_3 = qco.x %q0_2
%t0_3 = insert %q0_3, %t0_2, 0

// transformed to 
%q0_0, %t0_1 = extract %t0_0, 0
%q0_1 = qco.h %q0_0
%q0_2 = qco.x %q0_1
%t0_2 = insert %q0_2, %t0_1, 0

Maybe I am stupid, but this is the same right. It is also removing a "no-op", it's just not an extract-insert but an insert-extract one. Same same in my mind.

Wouldn't that be better suited in the ExtractOp.cpp file?

This is probably true nonetheless. I was initially thinking about putting it to the AllocOp.cpp file since it affects the tensor "globally".

Something really global would potentially better fit in the QTensorOps.cpp file, wouldn't it?
But I think at least the two Extract/Insert canons fit well in the respective files.

Furthermore: Does the bubbling canonicalization provide any "real" advantage besides sorting?

I would argue the following (may be irrelevant or invalid)

• The pattern(s) provide(s) a canonical tensor chain (something which we can't do with qubits).
• Consequently, makes the mapping pass work after unrolling (or any other future transformation) with the assumptions made in ♻️ Implement Explicit Assumption Checks for Mapping Pass #1716.

Lastly, the pattern has been inspired by the -bubble-down-memory-space-casts pass.

Fair points. It is probably reasonable to aim for a canonical ordering here.
Best case, this also provides a better starting point for the Extract/Insert canons requiring less iteration.
Convinced; let's keep it.

Moreso a general observation: At some point we may think about whether we really want to run the full canonicalization at every stage in our pipeline or whether we'd rather run more targeted sequences of patterns.
For example, I am not sure whether it really makes sense to run these particular passes more than once on a program.
This is definitely something for a follow-up though.

[MatthiasReumann]

Maybe I am stupid, but this is the same right.

Now that I think about it, you are right 🫠

At some point we may think about whether we really want to run the full canonicalization at every stage in our pipeline [...]

Probably also depends on how fast the end-to-end pipeline is, right?

[burgholzer]

At some point we may think about whether we really want to run the full canonicalization at every stage in our pipeline [...]

Probably also depends on how fast the end-to-end pipeline is, right?

Yeah, small potential inefficiencies like these are particularly noticeable now since we do not yet have sophisticated passes running by default.
I would suppose that the runtime of a mapping pass will overshadow most inefficiencies.
Which, nonetheless, is not a reason for not thinking about them.
In the end, we want the compiler to be as fast and efficient as possible.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!