QLDPC Compiler Module

[beitom]

Not sure if this is on the radar/in scope at all but thinking about how to eventually build a QLPC compiler (e.g. logical -> physical circuit generator) would be a great way to push this project to the next level.

The main motivation is that while we have TQEC working on 2D compilers for planar chips, there are no major open source efforts for reconfigurable/dense connectivity compilers where the resource gains from QLDPC codes traded with slower clock speeds are the main technology that would validate the advantages (if any) of these architectures. Most recent papers providing resource estimates (https://arxiv.org/pdf/2603.28627, https://arxiv.org/html/2505.15907v1) seem far from having full circuits ready. Clearly this is a huge non trivial problem, but thinking of a proof of concept project to build in this community could be very fruitful (e.g. specific code/algo combo). Interested in others thoughts on this direction.

[perlinm]

This would be wonderful functionality to have. Unfortunately, I do not have the bandwidth to drive this effort, but I would be very interested in supporting it to the degree that I can. Some quick thoughts that come to mind:

• Such a compiler would need to make a choice of quantum architecture or computational model. A reasonable starting point may be Pauli-based computation with extractors and adapters (which IBM is exploring for their BBCodes). But it should be clear that this is by far not the only choice available.
• I agree that picking a specific target problem is the way to go. We probably also need to pick a specific code (or code family) to start with, because there will be a lot to think about regarding how logical qubits are assigned to code blocks, and how to manage logical operations within vs. between code blocks. Maybe it would be reasonable to start with a small toy problem that fits on one code block (e.g., a small logical QPE or QFT circuit, or a Clifford proxy thereof, similar to arXiv:2511.20947).
• In the spirit of this library we should aim to make compiler implementations agnostic to the choice of code, at least to the degree that doing so is possible (TBD).
• Having made the point about code-agnostic implementations, in reality different codes will have different sets of "easy" operations (e.g., different sets of transversal gates). It would be nice for the compiler to be able to leverage this information somehow, though that's probably asking too much. We should aim to make the compiler modularized in such a way that code-agnostic bits of it can be used by other code-specific compilers. But I'm almost certainly getting ahead of myself here.
• I'll call out the Pinnacle Architecture as other potentially relevant background/motivating work.

UPDATE: having read arXiv:2603.28627 in more detail, I think that the computing architecture outlined therein also a reasonable choice for this project.

[beitom]

Thanks you for the comments! Unfortunately this is something that I also don't have the capacity to work on meaningfully but I thought it would be at least raise the issue so if someone comes along that is interested in qldpc compilation they might find this discussion.

[HaoTy]

Thanks for bringing this up! I've wondered for a while now whether qLDPC or some other package would like to explore this.

My understanding is that inter-block and intra-block compilations are two very different problems. The consensus seems to be generalized surgery for the former and more code-specific for the latter. I think for both, tailoring to the code properties will lead to a higher efficiency, but there's still value in providing an automatically generated, universal compilation based on code definitions.

I think #122 would be a good starting point for the former, but the package is not actively maintained. Also, tqec should be extensible to generalized surgery operations. Happy to be of help on this matter!

[perlinm]

arXiv:2603.28627 seems to have a nice scheme for separating inter- vs. in-block operations:

1. "In-block" (rather: in-processor, Clifford) operations are performed with generalized surgery to make Pauli-product measurements. This requires an ancillary system/code, so it technically still counts as an "inter-block operation" from the perspective of this library.
2. Inter-block operations are performed via logical Pauli-pair measurements across memory vs. processor blocks.

Appendix B has a lot of relevant technical details. This separation also makes it clear where code-specific compilers can come into play: they can leverage, say, code automorphisms (or other structure) for in-block processing as an alternative to (1) above. But a code-agnostic fallback/baseline would be very nice to have.

I would start with (2) above, with something like

@restrict_to_qubits
def teleport_logical_qubits(
    code_a: codes.QuditCode,
    code_b: codes.QuditCode,
    pairs_ab: Sequence[tuple[int, int]],
) -> stim.Circuit:
    """Circuit to fault-tolerantly teleport logical qubits from code_a to code_b.

    Here pairs_ab is a sequence of qubit pairs (q_a, q_b) that index, respectively, logical qubits
    in code_a and code_b.  For example, the logical Pauli Z operator for qubit q_a is
    code_a.get_logical_ops(Pauli.Z)[q_a].

    ...
    """
    assert all(0 <= q_a < code_a.dimension and 0 <= q_b < code_b.dimension for q_a, q_b in pairs)
    ...

Or maybe we should work at one level lower: an inter-block Pauli-pair product measurement that would be used for both teleportation and T state injection.

[perlinm]

Relevant: tqec/tqec#819

[tiangangzhou]

Hi! Based on the discussion above, I've implemented a lattice-surgery module for qLDPC codes in #512.

The PR adds gadget construction, single-PPM, and joint-PPM (via a universal adapter) for arbitrary qLDPC codes, following these papers:

Webster, Smith, Cohen — arXiv:2511.15989
Cain et al. — arXiv:2603.28627 §B.1
Swaroop, Jochym-O'Connor, Yoder — arXiv:2410.03628
Cross, He, Rall, Yoder — arXiv:2407.18393
Williamson, Yoder — arXiv:2410.02213

With this new API, one can run circuit-level simulations of qLDPC lattice surgery and obtain logical error rates. The included notebook walks through several usage examples. This is the first step towards the QEC compiler.