Some additional support for higher order objects #783
Conversation
There were a couple places in the data structure definitions that hardcoded assumptions about the order of the objects (to <1): * The length of the OBJECTS vector in a CHIP-SPEC. * The length of the CXNS vector in a HARDWARE-OBJECT. * Various constructors and initializers for building complete chip specifications. * The computation of the lookup cache. To solve this problem we introduce more general abstractions that cover the use case of building a chip-specification, as well as making on-demand adjustable vectors for those whose lengths depend on the order of the objects. To make sure this works we have an example chip spec consisting of just 3 qubits and a 3 qubit gate on them, that can do CCNOT.
Which usually manifests as an infinite recursive error. Setting up a proper condition class also allows us to handle this error in cases where the condition is not fatal.
* Distinguish between the cases of a hardware object being "dead" (which should strictly be declared in the chip specification), and the case of an object simply not having a "compiler path". (i.e. a sequence of compilation methods which sufficiently nativize given the gate set on the object). * Don't compute cost bounds for an instruction if doing so yields an infinite cycle in the compiler, since it may be the case that the compiler actually can nativize an instruction (e.g., but inserting the appropriate swaps), but cannot do so during chip specification warming.
Not because it's impossible, but because the code really doesn't support it yet.
This is to help ensure building chip specs and the bare minimum compilation of higher order objects keeps working.
There was a problem hiding this comment.
This looks like it takes the first few steps in a good direction. I left some comments, a couple of them trivial. I don't feel up to speed on quilc anymore, so don't take my 👍 as a clear sign that there's nothing left to think about, but I hope it's some comfort that there's nothing glaring to me.
I'm glad you picked up on how the permutation record stuff is just kinda dangling, and I hope you find a way to make good use of it!
| @@ -195,6 +195,13 @@ CNOT 0 2")) | |||
| ;; test on quality of compilation, and not on correctness. | |||
| (is (>= 6 (length 2q-code))))) | |||
|
|
|||
| (deftest test-native-ccnot-compilation () | |||
| ;; to help compute a bound on the single | ||
| ;; operation cost on this chip. This may be a | ||
| ;; source of non-determinism. | ||
| (let* ((instr (apply #'anon-gate "FLEX" (random-special-unitary (expt 2 qubits)) |
There was a problem hiding this comment.
I know you're just refactoring something gross I wrote, but I want to put on the record that this is a very poor kludge. I might open an issue.
| :protoquil (null registrant)))) | ||
| ;; order >1 hardware objects not yet supported by | ||
| ;; compressor. | ||
| (when (<= (length (chip-specification-objects chip-specification)) 2) |
There was a problem hiding this comment.
Prefer (>= 2 (length (chip-specification-objects chip-specification))).
| (dotimes (n *compressor-passes*) | ||
| (format-noise "COMPILER-HOOK: Compressing, pass ~D/~D." (1+ n) *compressor-passes*) | ||
| (setf processed-quil | ||
| (compress-instructions processed-quil chip-specification |
There was a problem hiding this comment.
Another note for another PR: it's probably the case both that the compressor as-is is going to be gnarly to modify to support higher-order hardware objects and that the variant suggested in #486 would be relatively straightforward. Consider including that ticket in this arc.
| @@ -314,6 +379,40 @@ used to specify CHIP-SPEC." | |||
| ;; return the link | |||
| obj)) | |||
|
|
|||
| (defun build-hardware-object (qubits &key type gate-information) | |||
There was a problem hiding this comment.
I see that qubits isn't bounded from above, but the contents of type make it sound specialized to order 2. Do you really want qubits to be unbounded? Or would you prefer something like build-triplet (or something similar)? Does it make sense to introduce a nontrivial type kwarg when that's the "legacy" data path?
This addresses some preliminaries of issue #438.