Added the preliminary list of reserved quantum operations

[kuzminrobin]

Continuation of the branch here

[kuzminrobin]

I would include the explicit matrix for each operation, and avoid any links to Q# documentation. QIR is intended to stand alone and be useful separate from Q#, so it's better if the QIR spec doesn't reference Q# documentation.

I would like to cover 2 aspects here.

1. My impression was that we need to unblock one of the hardware vendors ASAP. So the preliminary list does not need to be a final version. It needs to be a brief list we can quickly refer the vendor to. So in this preliminary list I tried to avoid text and matrix duplication as much as possible. @bettinaheim, please provide your opinion about that. Shall I start moving towards the final version of the list right now?
2. The cited fragment gives me somewhat new understanding. Let me summarize. Until recently my understanding was that QIR (Quantum Intermediate Representation) is generated to work in pair with the QIR RT (QIR Runtime), which is a part of the Q# compiler. And I was considering all 3 tightly tied together. Recently I hear more and more about using the QIR RT with other languages (which until now seemed to me more theoretical, for a remote prospective). And your comment, @alan-geller, sort of pushed me over some threshold after which I started thinking deeper about the languages other than Q#. Now my understanding is that the QIR and QIR RT are considered as a product potentially fully separate from Q# compiler (despite the fact that the QIR documentation is in the qsharp-language repo, and the QIR RT implementation is in the qsharp-runtime repo). By example of Figure 11.3 in Intro to LLVM, multiple frontends for multiple languages are considered/expected to generate the QIR (a subset of the LLVM IR), and in combination with the QIR RT the generated QIR will be used by multiple backends to generate the byte code for multiple quantum architectures. @alan-geller, @bettinaheim, please correct me if that understanding is not quite right.

[alan-geller]

I would include the explicit matrix for each operation, and avoid any links to Q# documentation. QIR is intended to stand alone and be useful separate from Q#, so it's better if the QIR spec doesn't reference Q# documentation.

I would like to cover 2 aspects here.

1. My impression was that we need to unblock one of the hardware vendors ASAP. So the preliminary list does not need to be a final version. It needs to be a brief list we can quickly refer the vendor to. So in this preliminary list I tried to avoid text and matrix duplication as much as possible. @bettinaheim, please provide your opinion about that. Shall I start moving towards the final version of the list right now?
2. The cited fragment gives me somewhat new understanding. Let me summarize. Until recently my understanding was that QIR (Quantum Intermediate Representation) is generated to work in pair with the QIR RT (QIR Runtime), which is a part of the Q# compiler. And I was considering all 3 tightly tied together. Recently I hear more and more about using the QIR RT with other languages (which until now seemed to me more theoretical, for a remote prospective). And your comment, @alan-geller, sort of pushed me over some threshold after which I started thinking deeper about the languages other than Q#. Now my understanding is that the QIR and QIR RT are considered as a product potentially fully separate from Q# compiler (despite the fact that the QIR documentation is in the qsharp-language repo, and the QIR RT implementation is in the qsharp-runtime repo). By example of Figure 11.3 in Intro to LLVM, multiple frontends for multiple languages are considered/expected to generate the QIR (a subset of the LLVM IR), and in combination with the QIR RT the generated QIR will be used by multiple backends to generate the byte code for multiple quantum architectures. @alan-geller, @bettinaheim, please correct me if that understanding is not quite right.

On your second point: yes, your understanding is correct. While the QIR spec is hosted in the Q# language repo for now, our intention is that QIR should be independent of Q# and usable with any quantum language. We are actually working with at least one partner who is using QIR as a back-end for other quantum languages already.

[kuzminrobin]

I guess I resolved all the feedback. Please review again.

[alan-geller]

I would include the explicit matrix for each operation, and avoid any links to Q# documentation. QIR is intended to stand alone and be useful separate from Q#, so it's better if the QIR spec doesn't reference Q# documentation.

I would like to cover 2 aspects here.

1. My impression was that we need to unblock one of the hardware vendors ASAP. So the preliminary list does not need to be a final version. It needs to be a brief list we can quickly refer the vendor to. So in this preliminary list I tried to avoid text and matrix duplication as much as possible. @bettinaheim, please provide your opinion about that. Shall I start moving towards the final version of the list right now?
2. The cited fragment gives me somewhat new understanding. Let me summarize. Until recently my understanding was that QIR (Quantum Intermediate Representation) is generated to work in pair with the QIR RT (QIR Runtime), which is a part of the Q# compiler. And I was considering all 3 tightly tied together. Recently I hear more and more about using the QIR RT with other languages (which until now seemed to me more theoretical, for a remote prospective). And your comment, @alan-geller, sort of pushed me over some threshold after which I started thinking deeper about the languages other than Q#. Now my understanding is that the QIR and QIR RT are considered as a product potentially fully separate from Q# compiler (despite the fact that the QIR documentation is in the qsharp-language repo, and the QIR RT implementation is in the qsharp-runtime repo). By example of Figure 11.3 in Intro to LLVM, multiple frontends for multiple languages are considered/expected to generate the QIR (a subset of the LLVM IR), and in combination with the QIR RT the generated QIR will be used by multiple backends to generate the byte code for multiple quantum architectures. @alan-geller, @bettinaheim, please correct me if that understanding is not quite right.

On your second point: yes, your understanding is correct. While the QIR spec is hosted in the Q# language repo for now, our intention is that QIR should be independent of Q# and usable with any quantum language. We are actually working with at least one partner who is using QIR as a back-end for other quantum languages already.

@bettinaheim , do you want to express an opinion on linking to Q# documentation in this page, at least for now? I think that's the last question before merging...

[bettinaheim]

@kuzminrobin "Now my understanding is that the QIR and QIR RT are considered as a product potentially fully separate from Q# compiler (despite the fact that the QIR documentation is in the qsharp-language repo, and the QIR RT implementation is in the qsharp-runtime repo)" They are indeed fully separate and independent entities. The repo setup as is is not great and we are currently exploring options for creating a fully separate repo for work around QIR. Hence, please do not refer to or mention Q# in any way as part of the QIR specs. While I appreciate the effort to be mindful of redundancies also in docs, the direction should go the other way around; QIR defines what meaning certain functions have if they are available, and what sets of instruction sets are commonly used. It should fully define that without linking to any external sources (including qsharp* repos or even the Q# specs here). To avoid redundancy, the Q# doc comment may choose to link to the definitions in the QIR specs for the corresponding operations.

[kuzminrobin]

/AzurePipelines help

[azure-pipelines[bot]]

Supported commands

• help:
• Get descriptions, examples and documentation about supported commands
• Example: help "command_name"
• list:
• List all pipelines for this repository using a comment.
• Example: "list"
• run:
• Run all pipelines or specific pipelines for this repository using a comment. Use this command by itself to trigger all related pipelines, or specify specific pipelines to run.
• Example: "run" or "run pipeline_name, pipeline_name, pipeline_name"
• where:
• Report back the Azure DevOps orgs that are related to this repository and org
• Example: "where"

See additional documentation.

[kuzminrobin]

/AzurePipelines list

[azure-pipelines[bot]]

No pipelines found for this repository.

[kuzminrobin]

/AzurePipelines where

[azure-pipelines[bot]]

No Azure DevOps organizations are setup to build repository microsoft/qsharp-language using the Azure Pipelines App.

[swernli]

I think we need to be more careful about how this asserts the way controls are used, namely it calls out a correlation between CNOT and __quantum__qis__x__ctl that I don’t think holds, because the latter supports arbitrary controls and not just one. We need to be careful not to let Q# patterns or abstractions like this overly influence how we define QIR instructions or it may hamper usability. Specifically here, I think we should avoid asserting anything about controlled gates that take an array of controls, since that assumes the runtime for the target supports arrays of qubits.

[kuzminrobin]

Agreed. I will make changes once I get back to this task.

[alan-geller]

Since the QIR specification has moved to https://github.com/qir-alliance/qir-spec, this PR can be closed.