Circuit Intermediate Representations

Short Definition

A circuit intermediate representation, or circuit IR, is a machine-checkable representation of a quantum–classical program used between source-level intent and a target executable. It specifies not only a syntax, but also operations, types, control and data dependencies, validity rules, capability assumptions, and enough semantics to decide whether a compiler transformation preserves the declared behavior.

An IR may be a textual interchange language, an in-memory graph, a static-single-assignment data structure, a hierarchy of regions and dialects, or a timed instruction stream. A file format is not automatically an IR, and an IR is not automatically a portable interchange standard.

This page is the canonical home for representation contracts: IR levels, quantum and classical value models, gate-set and capability declarations, lowering invariants, and portability. Quantum Software Stack owns the complete application-to-evidence path. Circuit Model owns circuit semantics and resource conventions, while Universal Gate Sets owns universality and approximation by gate alphabets. Gate Decomposition owns exact and approximate synthesis algorithms and their cost certificates. Circuit Optimization owns behavior-preserving circuit rewrites and abstract depth reduction. Later pages own mapping, routing, error-aware compilation, and pulse control.

Why a Compiler Needs Several Representations

Source programs and controller executables serve incompatible purposes. Source-level structure should retain functions, loops, symbolic parameters, data types, approximation intent, and named outputs. A controller needs concrete resources, supported instructions, resolved durations, legal parallelism, and bounded-latency branches. Lowering all structure immediately makes analysis and optimization harder; retaining all abstraction until dispatch makes deterministic execution impossible.

A useful abstract description of an IR is

$$\mathsf R = \bigl( \mathcal O,\, \mathcal T,\, \mathcal C,\, \mathcal M,\, \mathcal W \bigr),$$

where:

• $\mathcal O$ is the operation vocabulary and its semantics;
• $\mathcal T$ is the type and value system;
• $\mathcal C$ describes control flow, data flow, timing, and concurrency;
• $\mathcal M$ is semantic and provenance metadata;
• $\mathcal W$ is the set of well-formedness and verification rules.

A compiler judgment should be read schematically as

$$\mathsf R;\Pi;\Theta \vdash P:\tau_{\mathrm{out}},$$

where $P$ is the program, $\Pi$ is a capability profile, $\Theta$ is a versioned target contract, and $\tau_{\mathrm{out}}$ is the output schema. Leaving $\Pi$, $\Theta$, or $\tau_{\mathrm{out}}$ implicit is a common source of false portability claims.

There is no uniquely best IR for every stage. A compiler usually benefits from a family of forms:

1. a structured quantum–classical form near the source language;
2. a circuit, graph, or SSA form for analysis and transformation;
3. an encoded or logical form when error correction is introduced;
4. a target-native circuit with placement and instruction constraints;
5. a timed form for controller code generation;
6. an executable package with an explicit input and output contract.

Not every pipeline contains all six, and one multi-level language can cover several of them. The levels are semantic responsibilities, not required file extensions.

Lowering specializes a program toward a target. Each boundary must state what is preserved, what becomes concrete, and what information is intentionally discarded. Version, profile, units, output order, source maps, pass history, and target epoch remain part of the artifact contract.

Parseability Is the Weakest Contract

A successful parse proves only that a byte sequence matches a grammar. It does not prove that names resolve, types agree, quantum resources are used legally, the program belongs to a supported profile, or a target can execute it. The validation chain is closer to

$$\begin{aligned} b &\xrightarrow{\mathrm{parse}} A \xrightarrow{\mathrm{verify}} P_{\mathrm{typed}},\\ P_{\mathrm{typed}} &\xrightarrow{\mathrm{profile}} P_{\Pi} \xrightarrow{\mathrm{legalize}} P_{\Theta} \xrightarrow{\mathrm{codegen}} E. \end{aligned}$$

Here $b$ is serialized input, $A$ is an abstract syntax tree, $P_\Pi$ is profile-conformant IR, $P_\Theta$ is target-legal IR, and $E$ is an executable artifact. Each arrow can fail for a different reason and should produce a different diagnostic.

The distinction is operational:

Check	Question answered	Example failure
lexical and syntactic	Can the text be parsed?	missing delimiter or malformed literal
name and type	Are symbols, arities, widths, and units consistent?	two-qubit gate given one operand
structural	Do dominance, lifetime, region, and resource rules hold?	quantum value consumed twice
semantic	Does every operation have defined behavior?	gate name has no imported definition
profile	Does the program use an allowed feature subset?	adaptive branch in a terminal-measurement profile
target	Can this target realize the operations and constraints?	disabled coupler or unsupported reset
executable	Can the controller load and run the package?	instruction-memory or deadline violation
result	Can outputs be decoded as declared?	missing bit order or incompatible result schema

An interchange claim should therefore identify which checks are normative. The official OpenQASM grammar, for example, explicitly distinguishes syntactic validity from semantic correctness. The QIR specification similarly uses profiles and module metadata to constrain which LLVM-level programs a backend is expected to accept.

Minimum Semantic Payload

A mature circuit IR should make the following information representable or attach it through a normative companion contract.

Concern	Required information	Failure if omitted
quantum data	resource identity or value, type, lifetime, alias rules	accidental reuse, aliasing, or wrong subsystem
classical data	bit width, signedness, precision, mutability, lifetime	controller-dependent arithmetic
operations	name, arity, parameter domains, semantics, side effects	same spelling with different behavior
measurement	basis or instrument, result type, state-update convention	ambiguous branches and outputs
reset and release	postcondition and failure behavior	stale state reused as fresh state
control flow	branches, loops, calls, termination assumptions	compile-time loop mistaken for real-time control
data flow	definitions, uses, dependencies, memory effects	illegal reordering
gate conventions	tensor order, angle units, global phase policy	silently different unitaries
timing	duration units, alignment, barriers, concurrency intent	invalid or physically different schedule
input and output	names, shapes, ordering, accepted trials, schema	correct execution decoded incorrectly
approximation	metric, tolerance, allocation of error budget	unqualified synthesis change
provenance	language version, includes, passes, target epoch, source map	irreproducible or unauditable result

Some metadata is advisory, such as a display label. Other metadata changes meaning: a radians-versus-degrees tag, endianness declaration, calibration epoch, or measurement-output permutation cannot be dropped as decoration. An IR specification should distinguish the two classes.

Sequences, Graphs, Regions, and SSA

The visible gate diagram is only one possible data structure. Different forms expose different compiler facts.

Sequential and circuit-DAG forms

A static circuit can be represented as an ordered list or as a dependency graph

$$D = \bigl( V,\, E_q\cup E_c\cup E_t \bigr).$$

The vertices $V$ are operations. Quantum-resource edges $E_q$ order uses of the same subsystem, classical edges $E_c$ carry computed values, and timing or conflict edges $E_t$ impose additional order. A schedule $s(v)$ with duration $d(v)$ must satisfy

$$s(v)+d(v)\leq s(w),$$

for every required edge $(v,w)$.

A directed acyclic graph exposes commuting or independent regions and is natural for a statically expanded circuit. It is not by itself enough for a repeat-until-success loop, a measurement-conditioned branch, recursion, or an operation whose duration is unresolved.

Control-flow graphs and regions

A control-flow graph consists of basic blocks and directed transfers:

$$G_{\mathrm{cfg}}=(B,E_B).$$

Each block contains operations with one entry; a terminator chooses successor blocks. Measurement outcomes can therefore control later quantum operations. Structured regions retain higher-level constructs such as if, for, or a calibration block without immediately flattening them into jumps.

The distinction between compile-time and run-time control is essential. A loop whose trip count is known can be unrolled before dispatch. A loop whose exit condition depends on a measurement requires controller support, a termination policy, and often a latency bound while quantum data remain coherent.

Static single assignment

In static single assignment form, each SSA value has exactly one definition. Classical SSA makes definitions, uses, and merges explicit. Quantum IRs use two broad models:

• opaque mutable handles: a qubit identifier refers to a runtime resource, while operation side effects and memory-effect rules enforce ordering;
• functional quantum values: an operation consumes input quantum values and returns new SSA values representing the same evolving resources.

In the second model, a two-qubit operation has the schematic form

$$(q_1',q_2') = \mathsf{CX}(q_1,q_2),$$

and later operations use $q_1'$ and $q_2'$, not the consumed inputs. A simple linearity condition is

$$N_{\mathrm{consume}}(q_i)\leq 1$$

for each live quantum SSA value, with branch and region rules handling mutually exclusive uses. This is a static ownership rule, not a claim that a physical qubit is destroyed and recreated by every gate.

The no-cloning theorem does not select one syntax. It does rule out treating an unknown quantum value like an ordinary copyable SSA integer. A verifier must prevent illegal duplication through def-use chains, aliases, block arguments, arrays, and function calls. Linear and affine type systems, as well as quantum-specific SSA designs such as QSSA and QIRO, provide different ways to make this discipline checkable.

Multi-level dialects

Multi-level frameworks retain several abstraction-specific operation sets in one infrastructure. In MLIR terminology, operations produce typed values and are organized into blocks and regions; dialects define operation families, traits, interfaces, and verification rules. A quantum dialect can coexist with arithmetic, control-flow, tensor, and target dialects.

The benefit is controlled progressive lowering. The risk is assuming that a shared container supplies shared quantum semantics. An MLIR module is only as portable as the dialect definitions, versions, conversion contracts, and registered verifiers it depends on.

What Correct Lowering Must Preserve

For a closed unitary fragment $P$, its denotation is

$$\llbracket P\rrbracket(\rho) = U_P\rho U_P^\dagger.$$

If no surrounding construct can observe global phase, exact circuit equivalence permits

$$U_Q=e^{i\phi}U_P.$$

Approximate synthesis may instead require

$$\min_{\phi} \left\| U_Q-e^{i\phi}U_P \right\| \leq \epsilon_{\mathrm{synth}},$$

with a declared norm and error budget. This criterion is not enough for a dynamic program with measurement, reset, classical output, or measurement-conditioned control.

A dynamic program can be described by a quantum instrument $\{\mathcal I_y^P\}_y$, where each $\mathcal I_y^P$ is completely positive and trace-nonincreasing, and

$$\sum_y \mathcal I_y^P$$

is trace preserving on valid inputs. The corresponding classical–quantum output channel is

$$\mathcal E_P(\rho) = \sum_y |y\rangle\langle y|_C \otimes \mathcal I_y^P(\rho).$$

A lowering $L$ may add ancillas, physical measurements, frame updates, or internal records. Correctness is therefore observational:

$$\operatorname{dist} \left( \Pi_{\mathrm{out}}\mathcal E_{L(P)}, \mathcal E_P \right) \leq \epsilon_{\mathrm{decl}},$$

where $\Pi_{\mathrm{out}}$ discards or decodes internal artifacts and $\epsilon_{\mathrm{decl}}$ separates intentional approximation from physical noise. Quantum Instruments owns the instrument formalism. Noise in Quantum Information owns the distinction between compiler models and implemented noisy channels.

Compiler correctness consequently has several layers:

1. well-formedness preservation: the output IR passes its verifier;
2. semantic preservation: declared outputs agree exactly or within a stated metric;
3. resource refinement: newly introduced ancillas, operations, and timing are valid for the target;
4. contract preservation: input, output, failure, and acceptance conditions remain explicit;
5. provenance preservation: the lowered artifact can be traced to source, pass configuration, specification version, and target state.

Testing only unitary matrices can miss bit-order errors, dropped measurement records, altered postselection, or branch-dependent state updates.

Gate Sets Are Typed Capabilities

A gate set is not a list of attractive names. An operation needs a signature and semantics, schematically

$$\begin{aligned} g:\quad &\bigl( \tau_{q,1},\ldots,\tau_{q,k}; \\[-2pt] &\qquad \tau_{\alpha,1},\ldots,\tau_{\alpha,r} \bigr) \\ &\longrightarrow \bigl( \tau_{q,1}',\ldots,\tau_{q,k}' \bigr), \end{aligned}$$

together with $\llbracket g\rrbracket$, parameter domains, units, side effects, and legality conditions. The same identifier can denote different matrices, tensor-order conventions, phase conventions, or calibrated implementations in different ecosystems.

Five related objects should remain distinct:

Object	What it fixes	What it leaves open
gate alphabet	named unitary operations and parameter semantics	measurement, reset, control flow, target availability
quantum instruction set	callable quantum operations, possibly including irreversible actions	which program structures a backend accepts
capability profile	allowed types, control flow, allocation, outputs, and optional features	target topology and current resource state
target model	active resources, connectivity, native instruction instances, timing, conflicts	calibrated waveform implementation unless included
calibration library	binding from operations to pulses, frames, acquisitions, or microcode	higher-level program intent

Universality answers whether a family can approximate desired unitaries. It does not imply that a backend accepts mid-circuit measurement, dynamic allocation, arbitrary loops, real-time floating-point arithmetic, or a particular output schema. Conversely, a profile can permit adaptive control without prescribing one universal gate alphabet.

A defensible gate entry records at least:

• operation identity and namespace;
• arity and operand type;
• parameter type, unit, range, and precision;
• matrix or channel convention when target independent;
• control, inverse, and power semantics;
• virtual-versus-physical operand status;
• edge, zone, or module availability;
• duration and concurrency constraints when target bound;
• calibration and specification version.

Single-Qubit Gates develops rotation and phase conventions. Multi-Qubit Gates develops operand order, entangling capability, measured primitives, and native-versus-compiled contracts.

Lowering Is Controlled Information Loss

Let $P_i$ be a program in representation $\mathsf R_i$, and let $\Sigma_i$ carry proofs, semantic metadata, and provenance. A lowering pass has the form

$$\begin{aligned} (P_i,\Sigma_i) &\xRightarrow[\Theta,v_i]{L_i} (P_{i+1},\Sigma_{i+1}),\\ \mathsf R_i &\longrightarrow \mathsf R_{i+1}. \end{aligned}$$

The pass version $v_i$ and target contract $\Theta$ are part of the result. Each pass should declare:

• input and output dialects or schemas;
• preconditions and required analyses;
• invariants and approximation metric;
• features introduced, resolved, or removed;
• target assumptions;
• diagnostics for unsupported cases;
• source-map and provenance behavior.

Typical changes include:

Earlier representation	Lowering decision	Information no longer freely changeable
structured loops and calls	inline, specialize, or unroll	original hierarchy and compactness
symbolic gate operations	choose decomposition and basis	high-level gate identity
virtual qubits	place on target resources	target independence
unconstrained interactions	insert routing operations	original depth and error ledger
commuting operations	choose a schedule	much of the reordering freedom
symbolic durations	resolve target time units	device-independent timing
logical operations	choose code gadgets and factories	code independence
named measurements	assign acquisition channels and result slots	abstract output location

Information should be erased only after every pass that needs it has run. Conversely, preserving a stale high-level annotation after a transformation can be worse than removing it: metadata that claims an operation is logical or unitary after it has been replaced by measurement and feedforward is misleading.

Lowering need not be one-way in tooling. A disassembler can reconstruct a higher-level view, and a serializer can round-trip equivalent structures. Neither operation generally recovers discarded intent. Reconstructed loops, gate names, or source variables are hypotheses unless provenance retained them.

Portability Is a Ladder

“Portable” should always be qualified.

Level	Claim	What can still fail
syntactic portability	another tool parses the artifact	name, type, and semantic checks
semantic portability	operations and outputs have shared meaning	unsupported profile features
profile portability	backend advertises every required capability	target topology, limits, and timing
target portability	compiler can legalize the program	controller memory, deadlines, and calibration
operational portability	execution produces the declared records	noise, drift, acceptance, and schema handling
behavioral portability	declared output behavior agrees within tolerance	unequal resources or statistical uncertainty
reproducible portability	result can be regenerated and audited	unavailable versions, targets, or calibration state

Let $\operatorname{Cap}(P)$ be the capabilities required by a program and $\operatorname{Cap}(B)$ those advertised by a backend. A necessary profile condition is

$$\operatorname{Cap}(P) \subseteq \operatorname{Cap}(B).$$

Target execution additionally requires

$$\begin{aligned} &\operatorname{WellTyped}(P) \\ {}\land{}& \operatorname{Legal}(P,\Theta_B) \\ {}\land{}& \operatorname{Fits}(P,\Theta_B). \end{aligned}$$

Capability inclusion is not a performance guarantee. Two backends can execute the same semantic program while implementing different noisy channels, latencies, shot policies, or result acceptance rules.

A portable package should pin or declare:

1. language and serialization version;
2. capability profile and optional features;
3. imported libraries and gate definitions;
4. parameter units, numeric widths, and rounding;
5. qubit, tensor-factor, and classical-bit order;
6. input, output, failure, and postselection schemas;
7. target assumptions and any target-specific operations;
8. pass pipeline and approximation tolerances;
9. conformance tests, checksums, and provenance records.

The package can still be source portable without being binary portable. That is normal; it should not be described as “run anywhere” without the missing qualification.

Representative Standards and Designs

The following are representative, not a mandatory pipeline. Version statements are current at the page review date and should be rechecked against the linked specifications.

Representation or substrate	Principal role	Important boundary
OpenQASM 3.1	standalone, multi-level language for extended circuits, classical control, timing, and calibration constructs	parsing the language does not imply support for every construct or calibration grammar
QIR 2.0	LLVM-based representation using quantum instruction-set and runtime interfaces	a profile, QIS, output schema, and backend define the executable subset
QIR Base and Adaptive profiles	coherent capability subsets, from terminal measurement to measurement-conditioned control and optional richer features	profile support is separate from the chosen gate or quantum instruction set
Quil	instruction language for a quantum abstract machine with quantum and classical memory	abstract-machine portability does not bind one controller or calibration state
LLVM IR and MLIR	established SSA and multi-level compiler substrates	the substrate supplies structure and tooling, not quantum semantics by itself
QSSA and QIRO	research IRs using quantum-aware SSA and MLIR-based verification or optimization	their design results do not make every SSA encoding interchangeable
eQASM	executable quantum ISA with timing and controller concerns	a concrete architecture study is not a universal interchange standard

OpenQASM and QIR illustrate different choices. OpenQASM defines a quantum-focused language with its own types and circuit constructs. QIR defines how quantum programs are represented within LLVM IR and deliberately does not require every target to implement every runtime function or one universal gate set. Its Base Profile supports unitary sequences followed by terminal measurement and declared output; its Adaptive Profile adds mid-circuit measurement and forward branching, with further capabilities advertised separately.

These differences are useful. They prevent a format name from concealing the actual capability contract.

Worked Example: A Measurement-Conditioned Correction

Consider two qubits initialized in $|00\rangle$. Apply $H$ to $q_0$, then CNOT from $q_0$ to $q_1$, measure $q_0$ in the computational basis, and apply $X$ to $q_1$ when the result $m$ is one.

A language-neutral, functional SSA sketch is

func @prepare_and_correct(%q0: qubit, %q1: qubit)
    -> (bit, qubit) {
  %q0a = q.h %q0
  %q0b, %q1a = q.cx %q0a, %q1
  %m = q.measure_z %q0b
  %q1b = q.if %m -> qubit {
    %q1x = q.x %q1a
    q.yield %q1x
  } else {
    q.yield %q1a
  }
  return %m, %q1b
}

This is explanatory pseudocode, not syntax from a named standard. Its consume-and-return convention exposes the quantum def-use chain. A side-effectful IR could instead retain the identifiers q0 and q1 and model the operations as ordered effects.

Before measurement,

$$|\Phi^+\rangle = \frac{|00\rangle+|11\rangle}{\sqrt2}.$$

The measurement result is uniform. Conditioned on $m$, the second qubit is $|m\rangle$; the correction $X^m$ maps it to $|0\rangle$. The declared output is therefore

$$\begin{aligned} \rho_{\mathrm{out}} =\frac12\, |0\rangle\langle0|_m &\otimes |0\rangle\langle0|_{q_1}\\ +\frac12\, |1\rangle\langle1|_m &\otimes |0\rangle\langle0|_{q_1}. \end{aligned}$$

The IR and its verifier must preserve:

• that %m is a measurement result, not an arbitrary host Boolean;
• that the two branches are mutually exclusive;
• that each branch yields exactly one live version of $q_1$;
• that the merge value dominates later uses;
• that the output record labels and orders $m$ correctly;
• that the selected profile permits mid-circuit measurement and feedforward;
• that the target can make the decision before the next coherence-sensitive operation.

Suppose the only final use of $q_1$ is a computational-basis measurement $n$. Then one implementation may omit the physical correction and report

$$n_{\mathrm{corr}} = n\oplus m =0$$

in the ideal circuit. This is observationally equivalent for that declared classical output. It is not equivalent when $q_1$ is returned as quantum data or enters a later operation that does not commute with the frame update. An IR that retains output intent permits the optimization; a gate list with no output contract does not.

Verification and Translation Validation

An IR toolchain should reject unsupported programs before execution and detect miscompilation independently of a friendly visualization. A practical validation pipeline includes:

1. version and dependency resolution for the core schema, dialects, includes, and gate libraries;
2. parsing and deserialization with stable diagnostics;
3. name, type, width, and unit checking;
4. structural verification of dominance, regions, block arguments, lifetimes, aliasing, and quantum ownership;
5. profile conformance with explicit optional capabilities;
6. target legalization against active topology, instructions, timing, memory, and controller limits;
7. pass verification using proofs, translation validation, equivalence checking, or differential simulation appropriate to the semantics;
8. canonical serialization and hashing for artifact identity;
9. result-schema validation before scientific postprocessing.

Full compiler verification is valuable but difficult. Translation validation checks a particular input-output pair for a pass or pipeline. For unitary fragments this may use symbolic rewriting, decision diagrams, or matrix comparison at small scale. Dynamic circuits require tests of outcome distributions and conditional states, not merely a unitary equivalence tool.

Round-trip tests should compare semantic IR, not byte-for-byte formatting, unless the format specifies canonical serialization. Unknown mandatory operations or metadata should cause a hard failure. Silently dropping them turns forward compatibility into semantic corruption.

A reproducible executable identity can be modeled as

$$\begin{aligned} \operatorname{id}(E) =H\bigl(& \operatorname{bytes}(E), v_{\mathrm{spec}}, \Pi, \mathcal L,\\ &\mathcal P, \Theta_{\mathrm{epoch}}, \tau_{\mathrm{out}} \bigr), \end{aligned}$$

where $\mathcal L$ is the imported library set and $\mathcal P$ is the versioned pass pipeline. A source hash alone does not identify what ran.

Common Mistakes

• Treating successful parsing as proof of semantic or target compatibility.
• Calling every circuit file an IR without specifying operations, types, and validity rules.
• Assuming that equal gate names imply equal matrices, parameter units, or operand order.
• Confusing a universal gate set with a complete instruction or capability profile.
• Treating virtual qubit indices as physical resource identities.
• Applying unitary equivalence tests to programs with measurement, reset, postselection, or classical output.
• Copying an SSA quantum value into two consuming uses because ordinary integers are copyable.
• Lowering loops, symbolic gates, or output names before analyses that need them have run.
• Retaining metadata after a pass has invalidated its meaning.
• Dropping unknown mandatory metadata to make a newer artifact appear compatible.
• Expressing dt, angle, or integer literals without a unit and width contract.
• Reordering measurement records while preserving only a histogram shape.
• Advertising “cross-platform” execution without pinning profile, libraries, target assumptions, and result schema.
• Hashing source code but not the compiler, pass configuration, executable, or target epoch.

IR Evaluation Checklist

When evaluating a format or compiler IR, ask:

1. What is the semantic level: algorithmic, logical, native, timed, pulse, or executable?
2. Is it an internal data structure, a serialized interchange format, or both?
3. Which quantum and classical types exist, and which are copyable?
4. How are measurement, reset, release, and postselection represented?
5. Is control flow structured, graph based, statically unrolled, or dynamic?
6. What defines gate meanings, parameter units, tensor order, and global phase?
7. Which profile or optional capabilities does the program require?
8. How are target resources, timing, concurrency, and calibration attached?
9. What exact or approximate equivalence must each lowering pass preserve?
10. How are outputs named, ordered, validated, and connected to provenance?
11. What happens when a consumer encounters an unknown operation or metadata field?
12. Can the emitted artifact and result be reproduced from pinned inputs?

Exercises

1. Locate four different failures

A file passes its grammar, but it calls an undefined gate entangle; after a library is added, the program uses a measurement-conditioned branch forbidden by the selected profile; after selecting an adaptive profile, compilation finds that the required target coupler is disabled. Classify the three failures. What fourth check remains before the result can be interpreted?

Solution

The original file is syntactically valid but semantically incomplete because entangle has no resolved definition. The branch then produces a profile conformance failure. The disabled coupler is a target-legality failure.

After code generation and execution, the output still has to satisfy its result contract: schema version, field names, bit order, accepted-trial rule, and failure status must be checked before postprocessing. Controller loading and deadline checks can also fail between target legalization and a valid result.

2. Global phase and controlled use

For a closed one-qubit program, let $V=e^{i\phi}U$. Show that $U$ and $V$ produce the same density-operator channel. Then explain why replacing $U$ by $V$ inside a controlled operation is not generally harmless.

Solution

For any density operator $\rho$,

$$V\rho V^\dagger = e^{i\phi}U\rho U^\dagger e^{-i\phi} = U\rho U^\dagger.$$

The phase is global only when the operation acts unconditionally on the whole branch. A controlled version is

$$C(V) = |0\rangle\langle0|\otimes I + e^{i\phi}|1\rangle\langle1|\otimes U.$$

The factor $e^{i\phi}$ is now a relative phase between control branches. It can affect interference. An IR that supports automatic control modifiers must therefore retain enough phase information to define the controlled operation, even when the uncontrolled channel ignores global phase.

3. Derive the classical–quantum output

Derive the output state of the worked measurement-conditioned correction from $|00\rangle$. Verify both measurement probabilities and the conditional state of $q_1$.

Solution

After $H$ and CNOT,

$$|\Phi^+\rangle = \frac{|00\rangle+|11\rangle}{\sqrt2}.$$

Computational-basis measurement of $q_0$ gives $m=0$ or $m=1$, each with probability $1/2$. The corresponding state of $q_1$ is $|0\rangle$ or $|1\rangle$. Applying $X^m$ gives $|0\rangle$ in either branch. Retaining the classical record yields

$$\rho_{\mathrm{out}} = \frac12\sum_{m=0}^1 |m\rangle\langle m| \otimes |0\rangle\langle0|.$$

Discarding $m$ leaves $|0\rangle\langle0|$ on $q_1$, but that reduced state does not preserve the declared classical output.

4. Find the illegal SSA use

Consider the functional quantum SSA fragment

%qa = q.h %q
%u  = q.x %qa
%v  = q.z %qa

Why is it invalid, and what are two valid repairs with different meanings?

Solution

%qa has two consuming uses. The fragment attempts to evolve the same unknown quantum value along two simultaneously live paths.

A sequential repair is

%qa = q.h %q
%u  = q.x %qa
%v  = q.z %u

which implements $ZXH$. A conditional repair places the two uses in mutually exclusive branches and merges one yielded quantum value afterward. That implements either $XH$ or $ZH$ according to the branch condition. The two repairs are not semantically equivalent.

5. Audit a capability profile

A program requires mid-circuit measurement, forward branching, reset, and 32-bit integer arithmetic. Backend $A$ supports all but reset. Backend $B$ supports measurement, branch, and reset but only Boolean classical computation. Does either backend satisfy the profile directly? How could a legalization pass change the answer?

Solution

With

$$\operatorname{Cap}(P) = \left\{ \begin{array}{c} \mathrm{measure},\ \mathrm{branch}, \\ \mathrm{reset},\ \mathrm{int32} \end{array} \right\},$$

neither advertised capability set contains all requirements. Direct profile conformance fails for both.

A legalization may replace reset by a supported measurement-and-conditional operation if that sequence has the required reset postcondition on backend $A$. It may also constant-fold, narrow, or move the integer computation to a near-time host if doing so preserves timing and semantics on backend $B$. Those are compiler transformations with proof obligations, not permission to ignore the missing capabilities.

6. Explain why 20dt is not time portable

Two backends accept an instruction delay 20dt. Their controller sample periods are $0.5\,\mathrm{ns}$ and $2\,\mathrm{ns}$. Compare the physical delays. What contract would be needed to preserve a $10\,\mathrm{ns}$ intent?

Solution

The physical durations are

$$\begin{aligned} 20(0.5\,\mathrm{ns})&=10\,\mathrm{ns},\\ 20(2\,\mathrm{ns})&=40\,\mathrm{ns}. \end{aligned}$$

The syntax is portable but the timing is target dependent. A portable source contract can express $10\,\mathrm{ns}$ in an absolute duration type, together with an allowed quantization or rounding rule. Target lowering then converts that duration to sample units and rejects a target that cannot meet the declared tolerance.

7. Preserve output order

A two-qubit program declares output (parity, flag), but a backend returns two unlabeled bits in physical-qubit order. Why can a visually plausible histogram still be wrong? Give the minimum metadata needed to decode it.

Solution

Swapping the two fields permutes outcome labels while leaving the total number of shots and often the rough histogram shape unchanged. Correlations can also look plausible under a consistent but wrong bit permutation.

The result needs a schema version, mapping from acquisition or result slots to declared output fields, bit significance within aggregates, shot and accepted trial identifiers, and failure or missing-record status. Physical-qubit order is not a substitute for the source output contract.

8. Bound an observational rewrite

In the worked example, suppose $q_1$ is immediately measured in the computational basis and no later quantum operation acts on it. Show that omitting the conditional $X$ and reporting $n\oplus m$ preserves the ideal classical output. Give one change to the program that invalidates the rewrite.

Solution

Without the physical correction, the Bell correlations give $n=m$. Therefore

$$n\oplus m=0,$$

which matches the computational-basis measurement after applying $X^m$.

The rewrite fails if $q_1$ is returned as quantum data, if a later operation uses it coherently, or if the declared output includes the physical post-correction state rather than only the corrected classical bit. A later Hadamard followed by measurement is one concrete case where frame handling must be propagated rather than discarded.

9. Design a real-time error-correction profile

List the minimum IR features needed to represent a repeated stabilizer cycle with syndrome measurement, a bounded-latency decoder call, Pauli-frame update, and a fixed maximum number of rounds. Separate profile features from target properties.

Solution

Profile-level features include quantum and classical bit types, repeated or statically unrollable control, mid-circuit measurement, arrays or named collections of syndrome results, a decoder-call interface, conditional or frame-update operations, explicit outputs, and a way to attach deadline constraints. The profile should state whether the round count is compile-time constant and whether decoder arithmetic executes inside the controller or through an external real-time function.

Target properties include the available stabilizer-measurement primitives, active data and ancilla layout, operation durations, simultaneous-measurement capacity, reset support, acquisition routing, decoder and communication latency, instruction memory, and calibration epoch. Surface Code owns the code-cycle and logical interpretation; the IR profile owns how those requirements are represented and checked.

Research Status

The need for typed operations, explicit control and data flow, verifier contracts, target legalization, and provenance is durable compiler engineering. The best quantum value model, dialect boundaries, profile granularity, and cross-ecosystem interchange strategy remain active design questions.

At the August 2026 review date, the OpenQASM project identifies version 3.1 as current. The QIR specification describes QIR 2.0 and separates its Base and Adaptive profiles from the backend’s quantum instruction set. These are versioned projects, not timeless facts or proof of universal adoption. Compare specific pinned versions and conformance tests rather than format names alone.

Further Connections

• Quantum Software Stack places IRs between application semantics, compilation, runtime control, hardware response, and evidence.
• Circuit Model defines the ideal and dynamic circuit semantics an IR must preserve.
• Quantum Circuit Simulation consumes those semantics and makes wire order, gate definitions, measurements, classical state, output type, precision, and approximation part of an executable backend contract.
• Resource Estimation Tools consumes versioned logical artifacts and preserves call graphs, gate levels, liveness, schedules, model assumptions, and qualified physical outputs.
• Universal Gate Sets separates exact and approximate universality from backend capability.
• Gate Decomposition turns structured or dense unitary operations into verified circuits over a declared alphabet.
• Circuit Optimization uses typed dependencies, semantic fences, parameter domains, and provenance to simplify circuits without changing their declared behavior.
• Qubit Mapping and Routing consumes topology, direction, resource, timing, and output-map data from a target-aware IR.
• Error-Aware Compilation consumes calibration provenance, uncertainty, context, and validity intervals carried by target-aware IRs.
• Pulse-Level Control lowers target-bound operations into ports, frames, waveform plays, acquisitions, timing constraints, and versioned pulse certificates.
• Calibration Loops defines how parent versions, staleness, candidate snapshots, acceptance evidence, and atomic publication govern those target records.
• Hardware Overview defines the versioned target information consumed during legalization.
• Control, Readout, and Calibration owns waveform delivery, acquisition inference, physical tune-up dependencies, and feedback deadlines.
• Claims, Hype, and Evidence Standards explains why source, executable, target epoch, result schema, and postprocessing support different scientific claims.

References

1. A. W. Cross et al., “OpenQASM 3: A broader and deeper quantum assembly language,” ACM Transactions on Quantum Computing 3, 12 (2022), doi:10.1145/3505636.
2. OpenQASM contributors, OpenQASM Language Specification, current and versioned specifications, official repository.
3. QIR Alliance, Quantum Intermediate Representation Specification, including QIR version compatibility, quantum instruction-set interfaces, runtime contracts, and output schemas, official specification.
4. QIR Alliance, Base Profile and Adaptive Profile, official profile specifications.
5. R. S. Smith, M. J. Curtis, and W. J. Zeng, “A Practical Quantum Instruction Set Architecture,” arXiv:1608.03355 (2016), arXiv:1608.03355.
6. LLVM Project, LLVM Language Reference Manual, official documentation.
7. C. Lattner et al., “MLIR: Scaling Compiler Infrastructure for Domain Specific Computation,” 2021 IEEE/ACM International Symposium on Code Generation and Optimization, 2–14 (2021), doi:10.1109/CGO51591.2021.9370308.
8. MLIR Project, MLIR Language Reference, official documentation.
9. A. Peduri and S. Bhat, “QSSA: An SSA-Based IR for Quantum Computing,” Proceedings of the 31st ACM SIGPLAN International Conference on Compiler Construction, 2–14 (2022), doi:10.1145/3497776.3517772.
10. D. Ittah, T. Häner, V. Kliuchnikov, and T. Hoefler, “QIRO: A Static Single Assignment-Based Quantum Program Representation for Optimization,” ACM Transactions on Quantum Computing 3, 14 (2022), doi:10.1145/3491247.
11. P. Selinger and B. Valiron, “A Lambda Calculus for Quantum Computation with Classical Control,” Mathematical Structures in Computer Science 16, 527–552 (2006), doi:10.1017/S0960129506005238.
12. J. Paykin, R. Rand, and S. Zdancewic, “QWIRE: A Core Language for Quantum Circuits,” Proceedings of POPL 2017, 846–858 (2017), doi:10.1145/3009837.3009894.
13. X. Fu et al., “eQASM: An Executable Quantum Instruction Set Architecture,” 2019 IEEE International Symposium on High Performance Computer Architecture, 224–237 (2019), doi:10.1109/HPCA.2019.00040.
14. A. JavadiAbhari et al., “ScaffCC: Scalable Compilation and Analysis of Quantum Programs,” Parallel Computing 45, 2–17 (2015), doi:10.1016/j.parco.2014.12.001.
15. T. Häner et al., “A software methodology for compiling quantum programs,” Quantum Science and Technology 3, 020501 (2018), doi:10.1088/2058-9565/aaa5cc.
16. F. T. Chong, D. Franklin, and M. Martonosi, “Programming languages and compiler design for realistic quantum hardware,” Nature 549, 180–187 (2017), doi:10.1038/nature23459.