BarrierBeforeFinalMeasurement should be removed from transpiled circuit

[chriseclectic]

Environment

• Qiskit Terra version: 0.42.1
• Python version: 3.9
• Operating system: MacOS

What is happening?

When the transpiler does its routing pass, in some cases it inserts a barrier before final measurement. This barrier is not necessarily in the input circuit, and in cases where it is, it is expanded to span the full width of hte device rather than only the qubits of the input qubit.

If this barrier is not in the input circuit it should be removed from the transpiled circuit. If it is in the input circuit it should be only on the appropriately mapped qubits in the output circuit.

How can we reproduce the issue?

Example Circuit 1

First example is for a circuit with no barriers:

from qiskit import QuantumCircuit, transpile

qc = QuantumCircuit(2, 2)
qc.cx(0, 1)
qc.measure(range(2), range(2))

          ┌─┐   
q_0: ──■──┤M├───
     ┌─┴─┐└╥┘┌─┐
q_1: ┤ X ├─╫─┤M├
     └───┘ ║ └╥┘
c: 2/══════╩══╩═
           0  1 

Example Circuit 2

If I use measure_all which inserts a barrier, it gets expanded to all ancilla qubits:

              ░ ┌─┐   
   q_0: ──■───░─┤M├───
        ┌─┴─┐ ░ └╥┘┌─┐
   q_1: ┤ X ├─░──╫─┤M├
        └───┘ ░  ║ └╥┘
meas: 2/═════════╩══╩═
                 0  1 

Transpiled Circuits

If i force some complicated layout, in both cases the transpiled circuit has a full width barrier in it

transpile(qc, initial_layout=[1, 4], coupling_map=[[1, 2], [2, 3], [3, 4]]).draw()

                        ░       
ancilla_0 -> 0 ─────────░───────
                        ░       
      q_0 -> 1 ─X───────░───────
                │       ░ ┌─┐   
ancilla_1 -> 2 ─X───■───░─┤M├───
                  ┌─┴─┐ ░ └╥┘┌─┐
ancilla_2 -> 3 ─X─┤ X ├─░──╫─┤M├
                │ └───┘ ░  ║ └╥┘
      q_1 -> 4 ─X───────░──╫──╫─
                        ░  ║  ║ 
       meas: 2/════════════╩══╩═
                           0  1 

What should happen?

Expected transpiled circuit 1

                               
ancilla_0 -> 0 ────────────────
                               
      q_0 -> 1 ─X──────────────
                │        ┌─┐   
ancilla_1 -> 2 ─X───■────┤M├───
                  ┌─┴─┐  └╥┘┌─┐
ancilla_2 -> 3 ─X─┤ X ├───╫─┤M├
                │ └───┘   ║ └╥┘
      q_1 -> 4 ─X─────────╫──╫─
                          ║  ║ 
       meas: 2/═══════════╩══╩═
                           0  1 

Expected transpiled circuit 2

                               
ancilla_0 -> 0 ────────────────
                               
      q_0 -> 1 ─X──────────────
                │       ░ ┌─┐   
ancilla_1 -> 2 ─X───■───░─┤M├───
                  ┌─┴─┐ ░ └╥┘┌─┐
ancilla_2 -> 3 ─X─┤ X ├─░──╫─┤M├
                │ └───┘ ░  ║ └╥┘
      q_1 -> 4 ─X──────────╫──╫─
                           ║  ║ 
       meas: 2/════════════╩══╩═
                           0  1 

Any suggestions?

Add another transpiler pass to the generate_routing_passmanager that removes the barrier inserted by BarrierBeforeFinalMeasurement, and in the case where the original circuit has a barrier, preserve that barrier mapped to the appropriate qubits in the transpiled circuit.

[mtreinish]

Yeah I think ideally we should have an option to label the barrier BarrierBeforeFinalMeasurement inserts and later remove the labeled barriers before optimization. The barriers are only inserted for routing purposes so there isn't a reason for them to persist outside of the transpiler. This shouldn't be too hard to implement.

[kdk]

Are these barriers still necessary for routing? I don't believe they are needed for the backends anymore, so maybe BarrierBeforeFinalMeasurement can be removed from the default levels.

[mtreinish]

Yeah, they are still needed for routing. Without it sabre will potentially route past a measurement so we still rely on the inserted barrier for routing to work. To change this we'd have to give sabre more context about what a measurement is, it just treats it as a 1q operation right now.

[jakelishman]

I think they're not needed for backends, but a mid-circuit measurement (which these measurements become if swaps appear after them) have different error rates and performance characteristics than final measurements, so it's probably not ideal to be routing gates after them. It's also better for parallelisation of readout on basically any hardware architecture that can parallelise readout, I think?

Fwiw, I want to update Sabre with more context about every operation as a stepping stone to getting it to support mirror-gate synthesis and optimising the final circuit construction in Python space, and that would naturally tie into this as well. (edit: and I know what I'd do to do that update - I just haven't had time to actually do it.)