♻️ Refactor variantToValue to support different Value types #1465
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
📝 WalkthroughSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughTemplatizes Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📜 Recent review detailsConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (7)📓 Common learnings📚 Learning: 2025-12-05T17:45:37.602ZApplied to files:
📚 Learning: 2026-01-08T22:56:09.502ZApplied to files:
📚 Learning: 2025-10-14T14:37:38.047ZApplied to files:
📚 Learning: 2026-01-10T18:49:44.352ZApplied to files:
📚 Learning: 2025-12-01T11:00:40.342ZApplied to files:
📚 Learning: 2025-11-24T10:19:41.147ZApplied to files:
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (12)
🔇 Additional comments (2)
✏️ Tip: You can disable this entire section by setting Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@mlir/include/mlir/Dialect/Utils/Utils.h`:
- Around line 38-44: The Doxygen comment above the Convert-a-variant helper has
a mismatched parameter tag: change the incorrect "@param state" to "@param loc"
to match the actual function parameter name `loc`, and ensure the brief
description refers to `loc` (the operation location) if necessary so the
docblock parameters align with the function signature (look for the comment
around the function that converts a variant parameter to a Value in Utils.h and
update the `@param` tag).
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (29)
mlir/include/mlir/Dialect/Utils/Utils.hmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXPlusYYOp.cpp
🧰 Additional context used
🧠 Learnings (20)
📓 Common learnings
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:1045-1119
Timestamp: 2026-01-10T18:49:44.352Z
Learning: The QCOToQC conversion pass (mlir/lib/Conversion/QCOToQC/QCOToQC.cpp) does not need defensive mixed-type checks in its func conversion patterns (ConvertQCOFuncFuncOp, ConvertQCOFuncCallOp, ConvertQCOFuncReturnOp) because the conversion workflow always starts from QC to QCO, and the QCToQCO pass already enforces through its dynamic legality checks that func operations contain only qubit types (no mixed classical/quantum). This upstream guarantee justifies the all-qubit assumptions in QCOToQC patterns.
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Dialect/QCO/Builder/QCOProgramBuilder.cpp:599-757
Timestamp: 2026-01-12T12:05:56.683Z
Learning: In the QCO builder (mlir/lib/Dialect/QCO/Builder/QCOProgramBuilder.cpp), the SCF and func builder methods (scfFor, scfWhile, scfIf, funcCall) assume that all operands passed to them are qubit types (qco.qubit). The current validation through updateQubitTracking is sufficient for this use case. The same assumption applies to the QC builder methods.
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:988-1024
Timestamp: 2026-01-10T16:07:55.896Z
Learning: In the QCOToQC conversion pass (mlir/lib/Conversion/QCOToQC/QCOToQC.cpp), the SCF operation conversion patterns (ConvertQCOScfYieldOp, ConvertQCOScfConditionOp, ConvertQCOScfIfOp, ConvertQCOScfWhileOp, ConvertQCOScfForOp) assume that all operands are qubit types (qco.qubit or qc.qubit), never mixed qubit/classical types. The conversion is scoped to handle all-qubit SCF operations only.
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCToQCO/QCToQCO.cpp:1729-1763
Timestamp: 2026-01-10T16:28:41.975Z
Learning: In the QCToQCO conversion pass (mlir/lib/Conversion/QCToQCO/QCToQCO.cpp), the dynamic legality checks for func operations (func::CallOp, func::FuncOp, func::ReturnOp) and scf operations assume that operations use either all classical types or all qubit types, never mixed. Therefore, checking for the presence of qc::QubitType in operands or arguments is sufficient to determine if conversion is needed—there is no need to check both operands and results separately.
<!-- </add_learning]
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/include/mlir/Dialect/QCO/IR/QCOOps.td:259-259
Timestamp: 2025-12-17T17:44:31.349Z
Learning: In the QCO dialect (mlir/include/mlir/Dialect/QCO/IR/QCOOps.td), GPhaseOp intentionally uses `MemoryEffects<[MemWrite]>` instead of `Pure` to prevent the remove-dead-values pass from eliminating it. Since GPhaseOp is a zero-target operation with no result values, it would otherwise be removed by DCE, even though it has a meaningful effect on the global quantum state.
Learnt from: DRovara
Repo: munich-quantum-toolkit/core PR: 1108
File: mlir/lib/Dialect/MQTOpt/Transforms/DeadGateEliminationPattern.cpp:42-45
Timestamp: 2025-10-09T13:28:29.237Z
Learning: In the MQTOpt MLIR dialect, linear types enforce single-use semantics where each qubit value can only be consumed once, preventing duplicate deallocations and making RAUW operations safe when replacing output qubits with corresponding input qubits in transformation patterns.
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:1070-1085
Timestamp: 2026-01-07T12:29:16.380Z
Learning: In the QCOToQC conversion pass (mlir/lib/Conversion/QCOToQC/QCOToQC.cpp), the ConvertQCOFuncFuncOp pattern assumes that when a func.func operation is matched for conversion, all of its arguments are qco.qubit types (never mixed qubit/classical). The pattern unconditionally converts all arguments to qc::QubitType based on this assumption.
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Operations/StandardGates/PhaseOp.cpp:0-0
Timestamp: 2025-12-08T23:44:44.157Z
Learning: In MLIR code (mlir/ directories), avoid using const qualifiers on core MLIR data types like Value, Type, Attribute, Operation*, Block*, Region*, etc. in function parameters and signatures. MLIR's design rationale explicitly discourages const for these types. See https://mlir.llvm.org/docs/Rationale/UsageOfConst/ for details.
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:1040-1050
Timestamp: 2026-01-07T12:29:02.062Z
Learning: In the QCOToQC conversion pass (mlir/lib/Conversion/QCOToQC/QCOToQC.cpp), ConvertQCOFuncCallOp assumes that if a func::CallOp has qubit results, then all arguments and results are qubits (no mixed classical/quantum types). The conversion is scoped to handle all-qubit function calls only.
Learnt from: MatthiasReumann
Repo: munich-quantum-toolkit/core PR: 1237
File: mlir/include/mlir/Dialect/MQTOpt/Transforms/Transpilation/Layout.h:219-231
Timestamp: 2025-10-07T15:30:42.946Z
Learning: In the Layout class for MLIR quantum routing (mlir/include/mlir/Dialect/MQTOpt/Transforms/Transpilation/Layout.h), the swap method intentionally does NOT swap the hw fields in QubitInfo. This is correct because SSA values represent quantum states at fixed hardware locations, and only their program index associations change during a SWAP gate. The hw field indicates where an SSA value physically resides and remains constant.
📚 Learning: 2025-11-01T15:57:31.153Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1283
File: src/qir/runtime/QIR.cpp:196-201
Timestamp: 2025-11-01T15:57:31.153Z
Learning: In the QIR runtime (src/qir/runtime/QIR.cpp), the PRX gate (__quantum__qis__prx__body) is an alias for the R gate (Phased X-Rotation) and should call runtime.apply<qc::R>(theta, phi, qubit), not runtime.apply<qc::RX>() which is a single-parameter rotation gate.
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cpp
📚 Learning: 2025-10-09T13:20:11.483Z
Learnt from: DRovara
Repo: munich-quantum-toolkit/core PR: 1108
File: mlir/test/Dialect/MQTOpt/Transforms/lift-measurements.mlir:269-288
Timestamp: 2025-10-09T13:20:11.483Z
Learning: In the MQT MLIR dialect, the `rz` gate should not be included in the `DIAGONAL_GATES` set for the `ReplaceBasisStateControlsWithIfPattern` because its operator matrix does not have the required shape | 1 0 | / | 0 x | for the targets-as-controls optimization. It is only included in `LiftMeasurementsAboveGatesPatterns` where the matrix structure requirement differs.
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2025-12-08T23:44:39.930Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Operations/StandardGates/PhaseOp.cpp:0-0
Timestamp: 2025-12-08T23:44:39.930Z
Learning: In MLIR code under any mlir/ directory, avoid using const qualifiers on core MLIR types in function parameters/signatures (e.g., Value, Type, Attribute, Operation*, Block*, Region*, etc.). This aligns with MLIR's design rationale and should be applied to C++ source files (e.g., .cpp) within mlir/; see https://mlir.llvm.org/docs/Rationale/UsageOfConst/ for details.
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2025-12-17T11:32:45.843Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/LayeredUnit.cpp:83-86
Timestamp: 2025-12-17T11:32:45.843Z
Learning: In the mlir portion of munich-quantum-toolkit/core, prefer marking free functions as static (static linkage) over placing them in anonymous namespaces, per the clang-tidy rule llvm-prefer-static-over-anonymous-namespace. Do not apply this to type/class definitions; they may continue to use anonymous namespaces. This guideline should be checked across C++ source files under mlir/ (e.g., any free function in LayeredUnit.cpp) to ensure free functions have static linkage, while types/classes can remain in anonymous namespaces.
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2026-01-10T18:49:44.352Z
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:1045-1119
Timestamp: 2026-01-10T18:49:44.352Z
Learning: The QCOToQC conversion pass (mlir/lib/Conversion/QCOToQC/QCOToQC.cpp) does not need defensive mixed-type checks in its func conversion patterns (ConvertQCOFuncFuncOp, ConvertQCOFuncCallOp, ConvertQCOFuncReturnOp) because the conversion workflow always starts from QC to QCO, and the QCToQCO pass already enforces through its dynamic legality checks that func operations contain only qubit types (no mixed classical/quantum). This upstream guarantee justifies the all-qubit assumptions in QCOToQC patterns.
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2026-01-10T16:28:41.975Z
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCToQCO/QCToQCO.cpp:1729-1763
Timestamp: 2026-01-10T16:28:41.975Z
Learning: In the QCToQCO conversion pass (mlir/lib/Conversion/QCToQCO/QCToQCO.cpp), the dynamic legality checks for func operations (func::CallOp, func::FuncOp, func::ReturnOp) and scf operations assume that operations use either all classical types or all qubit types, never mixed. Therefore, checking for the presence of qc::QubitType in operands or arguments is sufficient to determine if conversion is needed—there is no need to check both operands and results separately.
<!-- </add_learning]
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cpp
📚 Learning: 2026-01-07T12:29:16.380Z
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:1070-1085
Timestamp: 2026-01-07T12:29:16.380Z
Learning: In the QCOToQC conversion pass (mlir/lib/Conversion/QCOToQC/QCOToQC.cpp), the ConvertQCOFuncFuncOp pattern assumes that when a func.func operation is matched for conversion, all of its arguments are qco.qubit types (never mixed qubit/classical). The pattern unconditionally converts all arguments to qc::QubitType based on this assumption.
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cpp
📚 Learning: 2026-01-12T12:05:56.683Z
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Dialect/QCO/Builder/QCOProgramBuilder.cpp:599-757
Timestamp: 2026-01-12T12:05:56.683Z
Learning: In the QCO builder (mlir/lib/Dialect/QCO/Builder/QCOProgramBuilder.cpp), the SCF and func builder methods (scfFor, scfWhile, scfIf, funcCall) assume that all operands passed to them are qubit types (qco.qubit). The current validation through updateQubitTracking is sufficient for this use case. The same assumption applies to the QC builder methods.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2025-12-02T07:37:46.860Z
Learnt from: MatthiasReumann
Repo: munich-quantum-toolkit/core PR: 1301
File: mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/sc/NaiveRoutingPass.cpp:144-151
Timestamp: 2025-12-02T07:37:46.860Z
Learning: In MLIR transformation code (mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/sc/NaiveRoutingPass.cpp and similar), when inserting operations before a target operation, prefer `rewriter.setInsertionPoint(op)` over `rewriter.setInsertionPointAfter(op->getPrevNode())`. The former is cleaner, avoids null pointer edge cases (when op is first in block), and is semantically clearer.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cpp
📚 Learning: 2025-12-17T17:44:31.349Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/include/mlir/Dialect/QCO/IR/QCOOps.td:259-259
Timestamp: 2025-12-17T17:44:31.349Z
Learning: In the QCO dialect (mlir/include/mlir/Dialect/QCO/IR/QCOOps.td), GPhaseOp intentionally uses `MemoryEffects<[MemWrite]>` instead of `Pure` to prevent the remove-dead-values pass from eliminating it. Since GPhaseOp is a zero-target operation with no result values, it would otherwise be removed by DCE, even though it has a meaningful effect on the global quantum state.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2025-12-08T23:58:09.648Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Modifiers/CtrlOp.cpp:80-100
Timestamp: 2025-12-08T23:58:09.648Z
Learning: In the Quartz dialect (mlir/lib/Dialect/Quartz/IR/Modifiers/CtrlOp.cpp), quartz.ctrl uses reference semantics and does not return values, unlike flux.ctrl which uses value semantics and returns transformed qubits. When inlining a GPhaseOp in the CtrlInlineGPhase pattern, it's correct to create POp operations for positive controls and erase the CtrlOp without collecting or replacing result values.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/RZZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/POp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2025-12-08T14:55:43.899Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Flux/IR/Modifiers/CtrlOp.cpp:78-100
Timestamp: 2025-12-08T14:55:43.899Z
Learning: In the Flux dialect (mlir/lib/Dialect/Flux/IR/Modifiers/CtrlOp.cpp), GPhaseOp is a zero-target operation (global phase). When a CtrlOp wraps a GPhaseOp, it only has control qubits and no targets. The CtrlInlineGPhase canonicalization pattern correctly produces outputs only for the positive controls, not targets.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cppmlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp
📚 Learning: 2026-01-10T17:31:22.110Z
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:816-862
Timestamp: 2026-01-10T17:31:22.110Z
Learning: In mlir/lib/Conversion/QCOToQC/QCOToQC.cpp, when creating scf::IfOp with `rewriter.create<scf::IfOp>(loc, types, condition, false)`, passing `false` for the withElseRegion parameter creates an else region that exists but contains no blocks. Therefore, inlineRegionBefore can be called on the else region without checking if it exists, and there's no need to erase an auto-created empty block from the else region (unlike the then region, which does get an auto-created empty block that must be erased).
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cpp
📚 Learning: 2025-10-09T13:13:51.224Z
Learnt from: DRovara
Repo: munich-quantum-toolkit/core PR: 1108
File: mlir/lib/Dialect/MQTOpt/Transforms/ReplaceBasisStateControlsWithIfPattern.cpp:171-180
Timestamp: 2025-10-09T13:13:51.224Z
Learning: In MQT Core MLIR, UnitaryInterface operations guarantee 1-1 correspondence between input and output qubits in the same order. When cloning or modifying unitary operations (e.g., removing controls), this correspondence is maintained by construction, so yielding getAllInQubits() in else-branches matches the result types from the operation's outputs.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cpp
📚 Learning: 2026-01-07T12:29:02.062Z
Learnt from: li-mingbao
Repo: munich-quantum-toolkit/core PR: 1396
File: mlir/lib/Conversion/QCOToQC/QCOToQC.cpp:1040-1050
Timestamp: 2026-01-07T12:29:02.062Z
Learning: In the QCOToQC conversion pass (mlir/lib/Conversion/QCOToQC/QCOToQC.cpp), ConvertQCOFuncCallOp assumes that if a func::CallOp has qubit results, then all arguments and results are qubits (no mixed classical/quantum types). The conversion is scoped to handle all-qubit function calls only.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cpp
📚 Learning: 2025-12-08T12:44:05.883Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Modifiers/CtrlOp.cpp:60-70
Timestamp: 2025-12-08T12:44:05.883Z
Learning: In the Quartz dialect (mlir/lib/Dialect/Quartz/IR/Modifiers/CtrlOp.cpp), negative controls are not supported at the current stage. The RemoveTrivialCtrl pattern correctly only checks getNumPosControls() when determining if a CtrlOp should be removed.
Applied to files:
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXMinusYYOp.cppmlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cpp
📚 Learning: 2025-10-07T15:30:42.946Z
Learnt from: MatthiasReumann
Repo: munich-quantum-toolkit/core PR: 1237
File: mlir/include/mlir/Dialect/MQTOpt/Transforms/Transpilation/Layout.h:219-231
Timestamp: 2025-10-07T15:30:42.946Z
Learning: In the Layout class for MLIR quantum routing (mlir/include/mlir/Dialect/MQTOpt/Transforms/Transpilation/Layout.h), the swap method intentionally does NOT swap the hw fields in QubitInfo. This is correct because SSA values represent quantum states at fixed hardware locations, and only their program index associations change during a SWAP gate. The hw field indicates where an SSA value physically resides and remains constant.
Applied to files:
mlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cpp
📚 Learning: 2025-12-08T23:44:44.157Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Operations/StandardGates/PhaseOp.cpp:0-0
Timestamp: 2025-12-08T23:44:44.157Z
Learning: In MLIR code (mlir/ directories), avoid using const qualifiers on core MLIR data types like Value, Type, Attribute, Operation*, Block*, Region*, etc. in function parameters and signatures. MLIR's design rationale explicitly discourages const for these types. See https://mlir.llvm.org/docs/Rationale/UsageOfConst/ for details.
Applied to files:
mlir/include/mlir/Dialect/Utils/Utils.h
📚 Learning: 2025-12-14T17:02:02.997Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Flux/Builder/FluxProgramBuilder.cpp:187-210
Timestamp: 2025-12-14T17:02:02.997Z
Learning: In the Flux dialect builder (mlir/lib/Dialect/Flux/Builder/FluxProgramBuilder.cpp), the coding style relies on implicit conversion from Value to ValueRange in ctrl() calls (e.g., `ctrl(control, {}, ...)` instead of `ctrl(ValueRange{control}, ValueRange{}, ...)`). This pattern is used consistently throughout all macro-generated methods and should be maintained for consistency.
Applied to files:
mlir/include/mlir/Dialect/Utils/Utils.h
🧬 Code graph analysis (2)
mlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cpp (1)
src/dd/StateGeneration.cpp (1)
state(126-126)
mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cpp (1)
src/dd/StateGeneration.cpp (1)
state(126-126)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Summary
🔇 Additional comments (30)
mlir/include/mlir/Dialect/Utils/Utils.h (2)
28-31: Verify:int64_tproduces IndexType, not IntegerType.This overload creates an
IndexAttr(yielding anindextype), which is intentional per the PR objectives. If a caller expects a standardi64integer constant, they would need a separate overload. Please confirm this is the desired behavior for all current and anticipated use cases.
23-26: LGTM!The
constantFromScalaroverloads fordoubleandboolare correctly implemented, and the templatedvariantToValuecleanly dispatches based on the variant's scalar type. This provides good extensibility while maintaining compile-time type safety.Also applies to: 33-36, 46-53
mlir/lib/Dialect/QC/IR/Operations/StandardGates/RXOp.cpp (1)
22-26: LGTM!The update correctly passes
state.locationto the refactoredvariantToValueAPI.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZXOp.cpp (1)
55-59: LGTM!The update correctly adapts to the new
variantToValuesignature.mlir/lib/Dialect/QC/IR/Operations/StandardGates/RYOp.cpp (1)
22-26: LGTM!The update correctly adapts to the new
variantToValuesignature.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/ROp.cpp (1)
73-79: LGTM!Both
thetaandphioperand construction correctly usestate.locationwith the refactoredvariantToValueAPI.mlir/lib/Dialect/QC/IR/Operations/StandardGates/RZOp.cpp (1)
22-26: LGTM!The change to pass
state.locationinstead of the fullstatetovariantToValueis correct and aligns with the refactoring to make the utility function more generic by accepting aLocationdirectly.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXMinusYYOp.cpp (1)
74-81: LGTM!Both
thetaOperandandbetaOperandconversions consistently usestate.location, maintaining the same pattern across all parameter conversions. The build method correctly delegates to the underlying build call with the resolved operands.mlir/lib/Dialect/QC/IR/Operations/StandardGates/XXPlusYYOp.cpp (1)
22-29: LGTM!The
variantToValuecalls for boththetaandbetaare consistently updated to usestate.location, matching the pattern established across other StandardGates operations in this refactor.mlir/lib/Dialect/QC/IR/Operations/StandardGates/GPhaseOp.cpp (1)
22-26: LGTM!The
variantToValuecall is correctly updated to usestate.location. This change is consistent with the broader refactoring pattern applied across all StandardGates operations.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/POp.cpp (1)
55-59: LGTM!The
variantToValuecall is correctly updated to passstate.locationinstead of the full state object, consistent with all other StandardGates operations updated in this PR.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/XXPlusYYOp.cpp (1)
78-80: LGTM!The refactored
variantToValuecalls correctly usestate.locationfor boththetaandbetaoperand construction, maintaining consistency with the broader PR pattern across all StandardGates operations.mlir/lib/Dialect/QC/IR/Operations/StandardGates/U2Op.cpp (1)
25-27: LGTM!Both
phiandlambdaoperand constructions consistently usestate.location, aligning with the refactoredvariantToValuesignature.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXXOp.cpp (1)
57-58: LGTM!The
thetaOperandconstruction correctly usesstate.location, consistent with the refactored utility signature.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZOp.cpp (1)
57-58: LGTM!The
thetaOperandconstruction correctly usesstate.location, consistent with the broader refactor.mlir/lib/Dialect/QC/IR/Operations/StandardGates/POp.cpp (1)
24-25: LGTM!The
thetaOperandconstruction correctly usesstate.location, completing the consistent pattern across all reviewed StandardGates operations.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/U2Op.cpp (1)
102-104: LGTM!The refactored
variantToValuecalls correctly usestate.locationto provide location context for operand materialization. This aligns with the broader PR goal of making the utility function generic while preserving the same behavior.mlir/lib/Dialect/QC/IR/Operations/StandardGates/RXXOp.cpp (1)
24-25: LGTM!Consistent refactoring to use
state.locationfor theta operand construction.mlir/lib/Dialect/QC/IR/Operations/StandardGates/ROp.cpp (1)
25-27: LGTM!Both theta and phi operand constructions correctly updated to use
state.location, maintaining consistency with the refactoredvariantToValueinterface.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RXOp.cpp (1)
57-58: LGTM!Consistent refactoring to use
state.locationfor theta operand construction in the QCO dialect's RXOp.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYYOp.cpp (1)
57-58: LGTM!Consistent refactoring to use
state.locationfor theta operand construction in the QCO dialect's RYYOp.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RYOp.cpp (1)
57-58: LGTM!The update to pass
state.locationdirectly tovariantToValuealigns with the refactored generic API. This is a clean change that correctly provides the location context needed for constant creation.mlir/lib/Dialect/QC/IR/Operations/StandardGates/RZZOp.cpp (1)
24-25: LGTM!Consistent application of the
state.locationpattern for the two-qubit RZZ gate.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/GPhaseOp.cpp (1)
50-51: LGTM!Correct update for the zero-target GPhaseOp, maintaining consistency with the location-based
variantToValuepattern.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/RZZOp.cpp (1)
57-58: LGTM!Consistent application of the refactored
variantToValueAPI for the QCO dialect's RZZ gate.mlir/lib/Dialect/QC/IR/Operations/StandardGates/RYYOp.cpp (1)
24-25: LGTM!Consistent application of the
state.locationpattern for the two-qubit RYY gate, completing the uniform refactoring across all standard gate operations.mlir/lib/Dialect/QCO/IR/Operations/StandardGates/UOp.cpp (1)
104-107: LGTM!The refactoring to use
state.locationinstead ofstateis applied consistently across all three operands (theta, phi, lambda). This aligns with the PR objective to makevariantToValuegeneric by acceptingLocationdirectly.mlir/lib/Dialect/QC/IR/Operations/StandardGates/RZXOp.cpp (1)
24-25: LGTM!The change correctly passes
state.locationtovariantToValue, consistent with the refactoring pattern across the codebase.mlir/lib/Dialect/QC/IR/Operations/StandardGates/XXMinusYYOp.cpp (1)
26-28: LGTM!Both
thetaOperandandbetaOperandconstruction correctly updated to usestate.location, maintaining consistency with the broader refactoring effort.mlir/lib/Dialect/QC/IR/Operations/StandardGates/UOp.cpp (1)
26-29: LGTM!The refactoring is applied consistently to all three angle operands. This mirrors the corresponding QCO dialect implementation and maintains the uniform approach across the codebase.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@mlir/include/mlir/Dialect/Utils/Utils.h`:
- Around line 46-53: The Location parameter must not be const-qualified: change
variantToValue's signature from "const Location& loc" to a non-const Location
parameter (e.g., "Location loc" or "Location &loc" consistent with surrounding
APIs) and update the constantFromScalar overloads called by variantToValue to
accept a non-const Location as well; then adjust any call sites if necessary to
match the new signatures. Ensure you modify the declarations/definitions for
variantToValue and the constantFromScalar overloads (and their forward
declarations) so they all use the same non-const Location type.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
mlir/include/mlir/Dialect/Utils/Utils.h
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Operations/StandardGates/PhaseOp.cpp:0-0
Timestamp: 2025-12-08T23:44:44.157Z
Learning: In MLIR code (mlir/ directories), avoid using const qualifiers on core MLIR data types like Value, Type, Attribute, Operation*, Block*, Region*, etc. in function parameters and signatures. MLIR's design rationale explicitly discourages const for these types. See https://mlir.llvm.org/docs/Rationale/UsageOfConst/ for details.
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Flux/Builder/FluxProgramBuilder.cpp:187-210
Timestamp: 2025-12-14T17:02:02.997Z
Learning: In the Flux dialect builder (mlir/lib/Dialect/Flux/Builder/FluxProgramBuilder.cpp), the coding style relies on implicit conversion from Value to ValueRange in ctrl() calls (e.g., `ctrl(control, {}, ...)` instead of `ctrl(ValueRange{control}, ValueRange{}, ...)`). This pattern is used consistently throughout all macro-generated methods and should be maintained for consistency.
📚 Learning: 2025-12-08T23:44:44.157Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Operations/StandardGates/PhaseOp.cpp:0-0
Timestamp: 2025-12-08T23:44:44.157Z
Learning: In MLIR code (mlir/ directories), avoid using const qualifiers on core MLIR data types like Value, Type, Attribute, Operation*, Block*, Region*, etc. in function parameters and signatures. MLIR's design rationale explicitly discourages const for these types. See https://mlir.llvm.org/docs/Rationale/UsageOfConst/ for details.
Applied to files:
mlir/include/mlir/Dialect/Utils/Utils.h
📚 Learning: 2025-12-14T17:02:02.997Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Flux/Builder/FluxProgramBuilder.cpp:187-210
Timestamp: 2025-12-14T17:02:02.997Z
Learning: In the Flux dialect builder (mlir/lib/Dialect/Flux/Builder/FluxProgramBuilder.cpp), the coding style relies on implicit conversion from Value to ValueRange in ctrl() calls (e.g., `ctrl(control, {}, ...)` instead of `ctrl(ValueRange{control}, ValueRange{}, ...)`). This pattern is used consistently throughout all macro-generated methods and should be maintained for consistency.
Applied to files:
mlir/include/mlir/Dialect/Utils/Utils.h
🧬 Code graph analysis (1)
mlir/include/mlir/Dialect/Utils/Utils.h (1)
mlir/include/mlir/Dialect/QCO/QCOUtils.h (1)
mlir(18-201)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: 🇨 Test 🍎 (macos-15, clang, Debug) / 🍎 macos-15 clang Debug
- GitHub Check: 🇨 Test 🐧 (ubuntu-24.04, gcc, Release) / 🐧 ubuntu-24.04 gcc Release
- GitHub Check: 🇨 Test 🐧 (ubuntu-24.04, gcc, Debug) / 🐧 ubuntu-24.04 gcc Debug
- GitHub Check: 🇨 Test 🍎 (macos-15-intel, clang, Release) / 🍎 macos-15-intel clang Release
- GitHub Check: 🇨 Test 🏁 (windows-2025, msvc, Debug) / 🏁 windows-2025 msvc Debug
- GitHub Check: 🇨 Test 🏁 (windows-11-arm, msvc, Release) / 🏁 windows-11-arm msvc Release
- GitHub Check: 🇨 Test 🐧 (ubuntu-24.04-arm, gcc, Release) / 🐧 ubuntu-24.04-arm gcc Release
- GitHub Check: 🇨 Test 🍎 (macos-15, clang, Release) / 🍎 macos-15 clang Release
- GitHub Check: 🇨 Lint / 🚨 Lint
- GitHub Check: 🇨 Coverage / 📈 Coverage
- GitHub Check: Summary
🔇 Additional comments (2)
mlir/include/mlir/Dialect/Utils/Utils.h (2)
15-15: LGTM!The
Location.hinclude is correctly added to support the newLocationparameter in the function signatures.
38-45: LGTM!The documentation is correct and the previous
@param statevs@param locmismatch has been fixed.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Contributor
Author
|
@denialhaag This is just a small change to reduce code duplication in #1396. |
denialhaag
reviewed
Jan 15, 2026
Member
There was a problem hiding this comment.
Thanks a lot for the quick turnaround! This looks good from my side, but I'd leave the final approval to @burgholzer! 🙂
Edit: Feel free to add the PR and your name to the changelog entry for the dialect redesign!
denialhaag
added
refactor
Signed-off-by: li-mingbao <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR templates the
variantToValuefunction to make the function more generic and to support the creation ofIndexTypeandI1Typeconstants.Required for #1396
Checklist: