Guppy program optimisation

[CalMacCQ]

We need an interface to call optimisation on quantum programs written in Guppy. In the near term this will be done by extracting a pytket Circuit from a HUGR and calling passes from pytket on the Circuit

Internally a HUGR graph would be converted to a pytket Circuit with function calls being converted to CircBoxes if they have a supported function signature. Unsupported Ops are encoded as barrier metadata.

We discussed the following points to enable this

1. Guppy gets a tket dependency

Program optimisation gets exposed to the user and is controllable client-side. Guppy will have a minimal interface for optimisation which users make use of via main.compile().

2. Guppy defines some sensible defaults for optimisation, just like pytket

a) Classical "structural" optimisation is fine. E.g. removing MakeTuple nodes
b) Intrusive quantum optimisations are off by default to respect fault tolerance. The possible exception to this is 1Q gate squashing. This doesn't change how Pauli faults propagate around the program so doesn't break fault tolerance.

So effectively the default optimisation level would be 0 (or 1 if we include 1q squashing). More intensive optimisations like KAKDecomposition and GreedyPauliSimp need to be explicitly opted into.

This will mean that we need a language guide section/notebook tutorial clearly documenting how to optimise programs and explaining the defaults.

3. How does the user control optimisation?

One such idea... pass a composite pass into .compile(), avoids multiple args in .compile

from tket.passes import QSystemPass

# We may want multiple optimisation levels for a given target like pytket-quantinuum.
my_pass = QSystemPass(opt_level=2, target=Qsystem.Helios)

@guppy
def main() -> None:
  ...
  
hugr_opt = main.compile(opt_pass=my_pass)

Another idea

from guppylang.builtins.optimize import OptLevel # OptLevelEnum, have named constants for different levels

hugr_opt = main.compile(opt_level=OptLevel.INTENSIVE) # OptLEVEL.INTENSIVE eqivalent to `opt_level=2`

4. Define a ComposablePass Protocol in hugr-py

We will define a ComposablePass protocol in hugr-py which will be implenented my passes in CQCL/tket2.

See Quantinuum/hugr#2617

5. CQCL/tket2 exposes pytket Passes in Python

from tket.passes import KAKDecomposition

 KAKDecomposition().apply(my_hugr)

Alternatively see #1300 (comment)

from tket.passes import KAKBuilder

kak_pass = KAKBuilder(max_search_depth=10)
kak_pass(my_hugr, in_place=True)

6. Passes act in place upon a Hugr

Passes are a Hugr -> Hugr transform. The user should be able to play around with passes on the Hugr in addition to using the main.compile() interface.

@guppy
def main() -> None:
  ...
  
hugr = main.compile()

pytket_pass.apply(hugr)

7. Rust ABI performance considerations

the tket Python interface is the only interface that promises performance. Because of this we will not bind any hugr-rs functions to hugr-py. This is for rust ABI reasons. See Quantinuum/hugr#2616

8. Optimisation within functions (future work).

Optimisation can take an entrypoint node for optimisation within Guppy functions. This requires that the user interpret the HUGR and find the appropriate FuncDefn node.

Longer term we could make an interface for users to configure optimsation within regions by using compiler directives in the Guppy decorator -> #567 .

[ss2165]

I'm not a fan of the ConstructPass().apply(hugr) interface, feels like a layover from pytket.
As a standalone problem the ideal one is new_hugr = pass(old_hugr). Two possible downsides:

• performance cost of not acting in place. Could adopt the in_place=True kwarg convention from numpy?
• Pass configuration. IMO this should be separate builder patterns that return a callable, e.g.:

my_pass = KAKBuilder(max_search_depth=10)
hugr = my_pass(hugr, in_place=True)

[aborgna-q]

We can also have the pass protocol implement call, so it works similarly to the function calls here but we get to type check them

[ss2165]

yeah I was thinking protocol implementing __call__ when I said "returns a callable"

[CalMacCQ]

Something like this?

from typing import Any, Protocol

class ComposablePassBuilder(Protocol):
    def __call__(self, *args: Any) -> ComposablePass:
        ...

[ss2165]

no, ComposablePass implements call and acts on Hugr

[acl-cqc]

Composition, we mentioned the idea of a compilationState, really a kind of LazyHugr - you can apply passes to it, and it just accumulates a list of them internally; only when you reify does it do the actual passes, all together. (I quite like this.)

However, composing ComposablePass (where you don't get to see the intermediates) provides another API that can achieve this, as long as the composition is done in Rust (i.e. no-one can use pdb to see the intermediates!).

[cqc-alec]

I think we should avoid "optimisation level" 0, 1, 2 etc. It gives the false impression that higher is always better, and gets hard to maintain. Prefer to have named passes.

[CalMacCQ]

Are there any cases where 2 is actually worse than 1? I think the fact that level 3 sometimes performs worse than 2 is that GreedyPauliSimp is a very differenent algorithm that does some global resynthesis.

[cqc-alec]

I'm not sure, but in any case there's no general "better than" relation on optimization passes, and as we can't shoehorn all passes into optimisation levels I don't see a compelling reason to use them at all. Names also convey more information.

[sjdilkes]

I agree with this - my perspective is that making "level 3" was a mistake (my mistake!) that has only caused confusion.

[CalMacCQ]

Could we just come up with explcit names for the different levels?

Perhaps enum values... Although we would have to come up with decent names. Could be tricky.

class OptLevel(Enum):
    MINIMAL = 0
    LIGHT = 1
    INTENSIVE = 2 #PEEPHOLE? Something else?
    GLOBAL = 3 # Maybe a bad name for this... GREEDY?

[acl-cqc]

QSystemPass is an awkward one. You can't not do a QSystemPass if you wanna run on a Q-System...

So some of this is more about passing options to passes that necessarily happen.

There's also the question of passes which may want to be kept private, i.e. without exposing results - most likely, these are Hugr->Opaque, and again, you can only give them options.