How could compiler optimisations be used with fault-tolerant quantum circuits?

Question

It is fairly well known that in a NISQ context you can often boost the fidelity of your quantum circuit by reducing the gate count and depth of your circuit. For example you can use the KAK decomposition to implement two qubit unitary blocks with at most three CNOT gates.

I'm curious about how compilers might work as we move towards fault-tolerant quantum computing. I've heard of work on minimising the "T-count" of circuits as T gates require a costly magic state distillation procedure to implement.

As is the case with NISQ circuits, fault tolerant circuits will still need to be routed to satisfy the connectivity constraints of the target architecture (if the architecture is not "fully connected").

If we naively try to reduce the gate count of a fault-tolerant circuit we may often end up removing gates which are essential for error correction to work properly.

Is there much research on optimising quantum circuits without breaking error correction? Is T gate reduction the most useful thing to focus on?

Answer 1

The compilation is, indeed, currently one of the best ways to increase the fidelity of a run. Also under the assumpution of fault-tolerant computation, compilation would eventually reduce the depth of a circuit, so that the run-time is reduced; which is not only important to mitigate noise, but also to make quantum computation faster.

As you say, a compiler should not mess with an error correction circuit. It is for this reason that an architecture should be engineered so that compilation does not interfere with error correcting protocols.

NISQ architectures, by definition, are not engineered to do so.

A "post-NISQ" architecture would eventually have enough resources to create a logical circuit, where each logical gate is fault-tolerant and a compiler would have no access to the physical implementation of each logical gate.

You may also think to an advanced compiler devoted to optimize the error correcting protocols, meaning that it would be created with a proper knowledge base, allowing it to preserve the defined fault-tolerant scheme.

Answer 2

A good strategy is to optimize the macroscopic and microscopic details of fault tolerance separately. At the microscopic level you focus on "how do I make a fault tolerant H gate available?" and then at the macroscopic level you focus on "how do I use this provided H gate the best?". You can separately focus on improving the internals of the H gates, and improving usage of the the exposed interface.

Although you could have one system try to optimize both the macro/micro parts simultaneously, this is hard. The fault tolerance aspects tend to make the circuit very strongly interlock with itself, such that you can't make changes without making other changes. The result is that the number of local changes you have to make to the physical circuit, to end up at something more efficient, is very large. A bad fault tolerant circuit is in a deep local minimum that's hard to get out of, if you're working at the microscopic level instead of the macroscopic level.

Also there's the issue that fault tolerant circuits don't just have to compute the right answer, they have to propagate errors in the correct way. It's easy to apply a circuit identity that exactly perfectly preserves the result computed by the circuit, but breaks the fault tolerance of the circuit. A direct-physical-circuit-optimizer has to be made more complicated to account for this, but then that constraint makes it basically impossible to apply local changes. Because most local changes initially look like mistakes in the pattern of the circuit, that make errors propagate wrong.