catalyst
catalyst copied to clipboard
PennyLaneAI
Move tapes from transform output to different functions
Transforms produce multiple tapes. We have the assumption that there is one tape per qfunc. Currently transforms is the only way to produce code that does not follow this convention. Do note that QIR does not specify this convention. But it helps keep the runtime simple to model, 1 quantum register allocated per function.
I agree, but I also think that it depends on what we want to do, either generalize functions to have an arbitrary number of quantum registers or limit it temporarily to only one register and separate them. I think we should generalize the functions to have an arbitrary number of quantum registers, but as an intermediate step to allow transforms to work along with allowing things like CSE, outlining tapes would be a good intermediate solution.
Happy if we generalize functions instead!
Is there something else that relies on the assumption of a single allocation per scope?
The issue with CSE and alloc is more a bug in the alloc definition in my opinion. For instance, the a assumption of one allocation per function would prevent inlining too.
Is there something else that relies on the assumption of a single allocation per scope?
I am not sure if there are many. I believe in the past (and possibly still today) deallocation of a register implied deallocation of the whole quantum state. This is a bit orthogonal to multiple allocations per scope, it would be multiple concurrent register allocations per scope. E.g.,
The following would be correctly allocated and deallocated
% 0 = quantum.alloc(5)
// ... snip ...
quantum.dealloc(%0)
// ... snip ...
% 1 = quantum.alloc(5)
quantum.dealloc(%1)
But in the following example:
% 0 = quantum.alloc(5)
% 1 = quantum.alloc(5)
// ... snip ...
quantum.dealloc(%1)
quantum.dealloc(%0)
The first deallocation would deallocate the whole quantum state. (i.e., 10 qubits).
@erick-xanadu @dime10 what is the current status of this issue 🤔 Do we want to edit it to reflect a technical improvement/feature?
The first deallocation would deallocate the whole quantum state. (i.e., 10 qubits).
I think that is only true for the specific implementation of our lightning runtime backends no? At worst it is an issue in the catalyst runtime not supporting several active registers, which is ok I think (in regards to top-level issue).
@erick-xanadu @dime10 what is the current status of this issue 🤔 Do we want to edit it to reflect a technical improvement/feature?
I do think we should update it to be either:
- an enhancement on the frontend to side to split out quantum tapes into different functions, with one benefit being that multi-tape transforms are compatible with the mlir gradient system for example
- an enhancement on the runtime/device backend side to support multiple registers (not sure how important this is though, right now nothing would really take advantage of it)
an enhancement on the frontend to side to split out quantum tapes into different functions, with one benefit being that multi-tape transforms are compatible with the mlir gradient system for example
Happy with this. If it can be done on the front-end or middle-end I am fine with either.
- an enhancement on the frontend to side to split out quantum tapes into different functions, with one benefit being that multi-tape transforms are compatible with the mlir gradient system for example
Currently multiple tapes are chained together by measuring the first tape, inserting a PauliX if 1 is measured, then perform the next tape.
This maneuver won't be necessary if multiple tapes are split into different functions.
