Skip to content

Latest commit

 

History

History
210 lines (191 loc) · 15.4 KB

TODO.md

File metadata and controls

210 lines (191 loc) · 15.4 KB
Raw

QIR-EE

Private repo for adapting QIR for use in XACC.

${\color{lightgreen}Abstract}$

The Quantum Intermediate Representation (QIR) provides an abstraction of programs that include a mixture of conventional and quantum instructions. This project develops a tool that translates a QIR program into a hardware-specific implementation using the XACC programming framework. This tool provides a unique capability to translating abstract QIR programs into executable programs on specific hardware. By mapping specific LLVM function calls to their corresponding C++ implementations, the code bridges the LLVM Execution Engine's classical execution environment with XACC's quantum computing capabilities. The integration allows for the smooth transition and combination of classical and quantum instructions, providing a unified platform for hybrid quantum-classical computing. The results from the quantum computations are captured in a globally accessible buffer, facilitating their use in classical post-processing or control logic.

${\color{lightgreen}Testing}$ ${\color{lightgreen} Instructions}$

  1. Dependencies (skip this step if you already did it):
    1. Install LLVM and XACC.
    2. Check that your cmake prefixes for XACC are correct.
      1. Typing echo $CMAKE_PREFIX_PATH should give you the path to your xacc installation.
      2. If empty, then add it: export CMAKE_PREFIX_PATH=[path to your xacc install]
      3. Example: [path to your xacc install] might be like $HOME/.xacc
    3. Check your $PYTHONPATH for the correct xacc. If empty or points to something else, then add it.
      1. export PYTHONPATH=$PYTHONPATH:$HOME/.xacc
  2. QIR-EE Setup:
    1. Clone this repo. Enter the repo.
    2. mkdir build; cd build
    3. cmake ..
    4. make
    5. To execute QIR: [a.] [b.] [c.] [d.] written without the brackets, where:
      1. ./QuantumExecutionEngine or an equivalent path to your executable
      2. ../examples/[name of *.ll file]
      3. number of shots (if left blank, then default is 1024)
      4. sim choice can be one of aer, qpp, qsim, honeywell:H1-1SC, honeywell:H1-1E, ionq (if left blank, then default is aer)

${\color{lightgreen}What}$ ${\color{lightgreen}is}$ ${\color{lightgreen}Here}$

The src/QuantumExecutionEngine.cpp integrates the XACC quantum computing framework with LLVM's Execution Engine to provide a seamless environment for executing both classical and quantum code. The Execution Engine runs the quantum code by calling mapped C++ functions, which in turn use XACC's quantum accelerators to execute the quantum circuit. These functions serve as the bridge between the LLVM Execution Engine and XACC's quantum execution environment.

${\color{lightgreen}Data}$ ${\color{lightgreen}Transfer}$ ${\color{lightgreen}from}$ ${\color{lightgreen}the}$ ${\color{lightgreen}Execution}$ ${\color{lightgreen}Engine}$

The XACC execution results are stored in a buffer, accessible through a Singleton pattern to ensure consistency and global access. C++ functions like quantum__qis__read_result__body and quantum__rt__result_record_output fetch data from this buffer. These functions are then dynamically linked to their LLVM counterparts (specified in the QIR) using LLVM's Execution Engine. This way, the quantum execution results can be used by subsequent classical computations in the LLVM code.

${\color{lightgreen}Handling}$ ${\color{lightgreen}Mixture}$ ${\color{lightgreen}of}$ ${\color{lightgreen}Quantum}$ ${\color{lightgreen}and}$ ${\color{lightgreen}Classical}$ ${\color{lightgreen}Instructions}$

The flexible architecture enables the combination of quantum and classical instructions. Quantum instructions are executed on the quantum accelerator via XACC, and the results are stored back into a common buffer. Classical operations can then read this buffer for further computation or conditional logic. Classical operations in the LLVM code can operate on the results of quantum computations through the mapped C++ functions. This makes it possible to design algorithms that interplay between classical and quantum computations, using the buffer as the common data link.

${\color{lightgreen}Dependencies}$

  1. XACC: The eXtreme-scale Accelerator programming framework is used for quantum computation.
  2. LLVM: The LLVM compiler infrastructure is required for the LLVM Execution Engine and for parsing LLVM IR files.

${\color{lightgreen}Current}$ ${\color{lightgreen} Structure}$

  1. Link LLVM via CMakeLists.txt
  2. Quantum Execution Engine (parses and executes quantum instructions only)
    1. Declare accelerator.
      1. auto accelerator = xacc::getAccelerator(accelerator_name);
    2. Parse *.ll for quantum instructions.
      1. Main block parsing. Example: bell.ll
      2. Persist through entire level one scope. Examples: teleport.ll, loop.ll
      3. Mutiple calls to an outside function. Example: multiple.ll
      4. Parameterized functions. Example: rotation.ll
      5. Implementations of functions for basic arithmetic with some user input. Example: input.ll
      6. Users can add instructions using the addMapping function.
    3. Construct quantum ciruit or kernel in XACCIR.
      1. Persist through entire level one scope.
      2. Extend to level two scope. This might include calls to external functions and user input.
    4. Use pointers to save readout.
    5. Execute quantum circuit on accelerator by checking global flag from readout.
      1. EE->addGlobalMapping(quantumFunc, (void*)&executeQuantumWithXACC)
  3. JIT Compilation and Execution
    1. LLVM EE created for JIT compilation.
    2. Quantum functions within LLVM module are mapped (or bound) to the QEE function.
    3. Main function of LLVM module is executed using LLVM EE.
    4. Quantum readout from hardware stored in buffer.
  4. Cleanup ouptut for user. Clear cache (if needed).

${\color{red}TODO}$ ${\color{lightgreen}For}$ ${\color{lightgreen}Public}$ ${\color{lightgreen}Release}$

  • Handling of multiple functions, multiple blocks, multiple entry points.
  • Handling of user created functions (related to above).
  • Handling of basic arithmetic with user input.
  • Check difference between requiredQubits and num_required_qubits in attributes.
  • If only classical code is present in *.ll file, insert "num_required_qubits"="0" inside list attributes #0.
  • Fix 'target' qubit output of if_else.ll.
  • Handling MIXED instruction with user input (what if user input is quantum input?).
  • Handle parameterized quantum circuits and operations.
  • LLVM version handling!
  • Add a variable for 'number of shots' input (but keep default at 1024).
  • Complete basic C++ implementations for quantum gate.
  • Two more examples to illustrate functionality (multiple gates and phase estimation algorithm).
  • Working with vendor emulators/simulators. Done: Quantinuum/Honeywell, IonQ.
  • Add 'enhanced' phase estimation to include loops and function calls (similar to qiskit's version in their tutorial).
  • Validation: Construct unit tests where we already know what the output should be.
  • Connect to IBM's hardware.
  • ${\color{red}ALERT}$ teleport.ll only runs correctly on aer. We expect it won't work on other simulators or hardware unless hardware can handle mid-circuit measurements.
  • Documentation 1: For Developers + In-Line
  • Documentation 2: Readthedocs for Users (What is our tool good for and how can users use it? This will depend on the integration step.)
  • Public usage: Release a self-contained package QIR-EE (pronouned 'curee'?) which wraps the Quantum Execution Engine with LLVM. Make into a cohesive whole with XACC.
  • Write the paper for the above implementation (shared in ShareLaTeX).

${\color{red}TODO}$ ${\color{lightgreen}Future}$ ${\color{lightgreen}Work}$

  • Possible integration with XACC as a utility? (But maybe not needed is package is standalone.)
  • Working beyond just XACC (possibly directly with different hardware backends).
  • Next level examples: variational algorithms, circuit optimizations.
  • Improve error handling: We should try to catch XACC failures. Also, what if the QIR contains quantum_rt_fail? When would this happen and how would we handle it?
  • Enhanced output record keeping: what other diagnostics can we expose from the XACC buffer? Currently we are doing bare minimum: shots. Can we do more?
  • Check/understand parallel implementations from Microsoft, Xanadu, Intel, Nvidia, Munich Team. Also: what is Quantinuum doing with runtime?

${\color{red}TODO}$ ${\color{lightgreen}Checklist}$ ${\color{lightgreen}For}$ ${\color{lightgreen}Implementations}$

  • void @__quantum__qis__h__body(%Qubit*)
  • void @__quantum__qis__x__body(%Qubit*)
  • void @__quantum__qis__y__body(%Qubit*)
  • void @__quantum__qis__z__body(%Qubit*)
  • void @__quantum__qis__t__body(%Qubit*)
  • void @__quantum__qis__t__adj(%Qubit*)
  • void @__quantum__qis__s__body(%Qubit*)
  • void @__quantum__qis__s__adj(%Qubit*)
  • void @__quantum__qis__mz__body(%Qubit*, %Result*)
  • void @__quantum__qis__reset__body(%Qubit*)
  • void @__quantum__qis__rx__body(double, %Qubit*)
  • void @__quantum__qis__ry__body(double, %Qubit*)
  • void @__quantum__qis__rz__body(double, %Qubit*)
  • void @__quantum__qis__cnot__body(%Qubit*, %Qubit*)
  • void @__quantum__qis__swap__body(%Qubit*, %Qubit*)
  • void @__quantum__qis__ccx__body(%Qubit*, %Qubit*)
  • void @__quantum__qis__cx__body(%Qubit*, %Qubit*)
  • void @__quantum__qis__cy__body(%Qubit*, %Qubit*)
  • void @__quantum__qis__cz__body(%Qubit*, %Qubit*)
  • void @__quantum__qis__rzz__body(double, %Qubit*, %Qubit*)

${\color{red}Other}$ ${\color{lightgreen}Not}$ ${\color{lightgreen}in}$ ${\color{lightgreen}XACC}$ ${\color{lightgreen}Common}$

  • void @__quantum__qis__rxx__body(double, %Qubit*, %Qubit*)
  • void @__quantum__qis__ryy__body(double, %Qubit*, %Qubit*)
  • void @__quantum__qis__r__body(i2, double, %Qubit*)
  • void @__quantum__qis__r__adj(i2, double, %Qubit*)

${\color{red}Other}$ ${\color{lightgreen}Array}$ ${\color{lightgreen}Stuff}$

  • void @__quantum__qis__h__ctl(%Array*, %Qubit*)
  • void @__quantum__qis__x__ctl(%Array*, %Qubit*)
  • void @__quantum__qis__y__ctl(%Array*, %Qubit*)
  • void @__quantum__qis__z__ctl(%Array*, %Qubit*)
  • void @__quantum__qis__t__ctl(%Array*, %Qubit*)
  • void @__quantum__qis__t__ctladj(%Array*, %Qubit*)
  • void @__quantum__qis__rx__ctl(%Array*, %Tuple*)
  • void @__quantum__qis__ry__ctl(%Array*, %Tuple*)
  • void @__quantum__qis__rz__ctl(%Array*, %Tuple*)
  • void @__quantum__qis__r__ctl(%Array*, %Tuple*)
  • void @__quantum__qis__r__ctladj(%Array*, %Tuple*)
  • void @__quantum__qis__s__ctl(%Array*, %Qubit*)
  • void @__quantum__qis__s__ctladj(%Array*, %Qubit*)
  • %Array* @__quantum__rt__array_concatenate(%Array*, %Array*)
  • %Array* @__quantum__rt__array_copy(%Array*, bool)
  • %Array* @__quantum__rt__array_create_1d(i32, i64)
  • i8* @__quantum__rt__array_get_element_ptr_1d(%Array*, i64)
  • i64 @__quantum__rt__array_get_size_1d(%Array*)
  • %Array* @__quantum__rt__array_slice_1d(%Array*, %Range, i1)
  • void @__quantum__rt__array_record_output(i64, i8*)
  • void @__quantum__rt__array_update_alias_count(%Array*, i32)
  • void @__quantum__rt__array_update_reference_count(%Array*, i32)

${\color{red}Other}$ ${\color{lightgreen}Measure,}$ ${\color{lightgreen}Results,}$ ${\color{lightgreen}Strings,}$ ${\color{lightgreen}Tuples}$

  • %Result* @__quantum__qis__m__body(%Qubit*)
  • %Result* @__quantum__qis__measure__body(%Array*, %Array*)
  • %Result* @__quantum__qis__mresetz__body(%Qubit*)
  • bool @__quantum__qis__read_result__body(%Result*)
  • bool @__quantum__rt__result_equal(%Result*, %Result*)
  • %Result* @__quantum__rt__result_get_one()
  • %Result* @__quantum__rt__result_get_zero()
  • void @__quantum__rt__result_record_output(%Result*, i8*)
  • void @__quantum__rt__result_update_reference_count(%Result*, i32)
  • %String* @__quantum__rt__result_to_string(%Result*)
  • %String* @__quantum__rt__string_concatenate(%String*, %String*)
  • %String* @__quantum__rt__string_create(i8*)
  • bool @__quantum__rt__string_equal(%String*, %String*)
  • i8* @__quantum__rt__string_get_data(%String*)
  • i32 @__quantum__rt__string_get_length(%String*)
  • void @__quantum__rt__string_update_reference_count(%String*, i32)
  • %Tuple* @__quantum__rt__tuple_copy(%Tuple*, i1)
  • %Tuple* @__quantum__rt__tuple_create(i64)
  • void @__quantum__rt__tuple_record_output(i64, i8*)
  • void @__quantum__rt__tuple_update_alias_count(%Tuple*, i32)
  • void @__quantum__rt__tuple_update_reference_count(%Tuple*, i32)

${\color{lightgreen}Funding}$

This work was performed at Oak Ridge National Laboratory, operated by UT-Battelle, LLC under contract DE-AC05-00OR22725 for the US Department of Energy (DOE). Support for the work came from the DOE Advanced Scientific Computing Research (ASCR) Accelerated Research in Quantum Computing (ARQC) Program under field work proposal ERKJ332.