WIP: [Adding Specification for the Adaptive Profile] #35
Conversation
…fixed point numbers.
There was a problem hiding this comment.
I was asked to take a look, so here are some quick comments. I'll come back later when I have time.
One question I couldn't find a suitable place for based on a quick search is a way for backends to specify whether they want their loops unrolled (if possible) or not.
…d on last week's discussion
| Adaptive Profile compliance with additional features. A maximal Adaptive Profile program adds | ||
| all of the following capabilities. The extended possible Adaptive Profile capabilities a program can express are: | ||
|
|
||
| 8. Qubit resetting (`__quantum__qis__reset__body` supported in the instruction set). |
There was a problem hiding this comment.
arguably, at least naive implementations of this feature are covered by features 4-7. is there a reason 8 is not in the same section as those?
There was a problem hiding this comment.
I think one could still have branching features and conditional gates based on say random number generation if a back-end has support for extern function call outs.
| point arithmetic calculations of a back-end specified width, or logical operations | ||
| on integers of a back-end specified width. Front-ends can use any integer width when generating code, | ||
| and it is the responsiblity of a back-end to provide a compile-time error message if the front-end | ||
| uses an integer width greater than that which the support. |
There was a problem hiding this comment.
two concerns:
- an end-user would be working with a "high level" data type which is likely to imply high width (so how would they know), and
- therefore some mechanism for lowering the width would need to happen somewhere (breaking this guidance)
Personally, I wouldn't be excited about having to deal with explicit typing (e.g., numpy's dtype) either as an end-user or working on a backend. On the other hand, rigor is good too...
There was a problem hiding this comment.
We intend to update the spec to have the module flag explicitly specifying the used data type size(s). The backend should then look at these flags and reject the program if it does not provide support for these sizes.
There was a problem hiding this comment.
One thing that isn't clear from reading, and it seems this context also switches depending upon topic, is whether the spec views QIR to be run almost-directly on a QPU, or whether it's executed by a runtime which provides classical support and that calls to a QPU.
It talks about classical results post-processing on one hand, then about how memory on the FPGA should be highlighted to consumer systems on the other. I've always considered it (relatively) high-level - your QIR is the basic outline of what you'd like to run, including all contextual information added to help the backend run your request better. Especially since if you implement the full QIR spec you can send classical programs with fragments of quantum in it and run them directly.
While you can interpret it at both levels, and it depends upon what sort of backend you have, certain assertions and constraints don't apply depending upon what lens you look at it though.
Also out of curiosity: is this the outcome of some working group?
…rguments, and the connection of module flags to output recording functions
This VSCode extension is amazing: https://marketplace.visualstudio.com/items?itemName=TakumiI.markdowntable
Fix issues reported my markdownlint, typos
|
CLA Assistant Lite bot: I have read the Contributor License Agreement and I hereby accept the Terms. 3 out of 4 committers have signed the CLA. |
|
|
||
| ### Bullet 3: Program output | ||
|
|
||
| There is no change to output specifications with respect to the base profile, sans for the |
There was a problem hiding this comment.
Error codes are no longer present in the spec. Non-zero return values indicate an error has occurred, but are all provider/backend specific.
| | __quantum__rt__array_record_output | `void(i64,i8*)` | Inserts a marker in the generated output that indicates the start of an array and how many array elements it has. The second parameter defines a string label for the array. Depending on the output schema, the label is included in the output or omitted. | | ||
| | __quantum__rt__result_record_output | `void(%Result*,i8*)` | Adds a measurement result to the generated output. The second parameter defines a string label for the result value. Depending on the output schema, the label is included in the output or omitted. | | ||
| | __quantum__rt__bool_record_output | `void(i1,i8*)` | Adds a boolean value to the generated output. The second parameter defines a string label for the result value. Depending on the output schema, the label is included in the output or omitted. | | ||
|
|
There was a problem hiding this comment.
We need to update the output recording formats to include any changes in recording varying bit widths for int, float, fixed.
Cleanup writing form Bettina.
|
|
||
| ## Runtime Functions | ||
|
|
||
| The following runtime functions must be supported by all backends: |
There was a problem hiding this comment.
This table is missing the __quantum__rt__bool_record_output function.
| Additionally, the Adaptive Profile imposes the following restrictions on qubit | ||
| and result usage: | ||
|
|
||
| - Qubits must not be used after they have been passed as arguments to a function |
There was a problem hiding this comment.
This seems inconsistent with the rest of the specification. Up to this point, qubit reuse is a required capability, but this point conveys the message that qubit reuse is not supported in an adaptive profile program.
| support more advanced adaptive computations: | ||
|
|
||
| <!-- markdownlint-disable MD029 --> | ||
| 5. Computations on classical (non-composite) data types, specifically on |
There was a problem hiding this comment.
This point mentions fixed-point numbers, which should not be included.
| !3 = !{i32 1, !"dynamic_result_management", i1 false} | ||
| !4 = !{i32 5, !"int_computations", !""} | ||
| !5 = !{i32 5, !"float_computations", !""} | ||
| !6 = !{i32 5, !"fixedpoint_computations", !""} |
There was a problem hiding this comment.
This sample contains a the fixedpoint_computations module flag which is no longer part of the spec.
| floating point numbers of all listed precisions must be supported by the | ||
| executing backend. An empty value indicates that no floating-point | ||
| computations are supported/used. | ||
| - a flag with the string identifier `"fixedpoint_computations"` that contains a |
There was a problem hiding this comment.
This point should be removed since fixed point computations are no longer part of the adaptive profile spec.
| computations with precision `2N`, and it must be able to process constant | ||
| integer values of type `i32` being passed as scale. See also the [LLVM | ||
| Language | ||
| Reference](https://llvm.org/docs/LangRef.html#fixed-point-arithmetic-intrinsics). |
There was a problem hiding this comment.
This point should also be removed since it references fixed point computations.
| Allow to define and use global constants for (only) the supported data types. | ||
| --> | ||
|
|
||
| ### Bullet 6: IR-defined functions and function calls |
There was a problem hiding this comment.
I think a few more restrictions are required on IR-defined functions:
- Calls to IR-defined functions should only take constant
%Qubitand%Resultarguments. - Currently, it is specified that IR-defined functions can return a value of type
%Result. I think this should not be the case because it would require dynamic result allocation. - Within IR-defined functions, the only
%Qubitand%Resultvalues that can be used are the ones coming from arguments.
| `inlinehint`, `nofree`, `norecurse`, `readnone`, `readonly`, `writeonly`, and | ||
| `argmemonly`. |
There was a problem hiding this comment.
Is there a reason to highlight this specific set of LLVM attributes? I would think that if someone includes certain attributes LLVM attributes in their QIR program, consumers of that program can use some of them as hints for processing it but it would be up to them which specific attributes will have special handling.
Revision for clarity and distinction of two kinds of loops
…ints is described in writing about module flags, and remove %Result from a return type for IR-defined functions and make it so that it must be a standard classical type from the extension
Trying this again. I expect linting issues but hopefully no committer/CLA issues. Initial draft of the specification here for public comments.