✨ Recognize unitary OpenQASM gates with structured control flow #2413
Copy link
Copy link
Closed
Labels
MLIRAnything related to MLIRAnything related to MLIROpenQASMAnything related to OpenQASMAnything related to OpenQASMenhancementImprovement of existing featureImprovement of existing feature
Milestone
Description
Activity
- addedenhancementImprovement of existing featureImprovement of existing featureMLIRAnything related to MLIRAnything related to MLIROpenQASMAnything related to OpenQASMAnything related to OpenQASM
on Sep 6, 2026 - added 2 commits that reference this issue
on Oct 5, 2026
Metadata
Metadata
Assignees
Labels
MLIRAnything related to MLIRAnything related to MLIROpenQASMAnything related to OpenQASMAnything related to OpenQASMenhancementImprovement of existing featureImprovement of existing feature
🤖 AI text below 🤖
Problem Statement
OpenQASM import currently marks every custom gate that requires structured control flow as non-unitary. This includes gates with statically bounded
forloops whose bodies contain only unitary operations. Callers of such gates also remain non-unitary, which prevents later unitary-only handling even when the source gate is safe.This follows up on the final review of #2338.
Proposed Solution
Add conservative unitary recognition for structured custom-gate bodies. Support at least statically bounded
forloops whose bodies contain only unitary operations or calls to unitary gates. Propagate the result through callers.Leave functions unmarked when they contain non-unitary operations, recursion, unresolved calls, or unsupported control flow. Add import and round-trip tests for accepted loops and rejected non-unitary bodies.