qir-alliance / qat Goto Github PK

Q# needs updating in the project files.

Straight-line code validation needs reordering.

The running QAT | Grouping QIS (https://www.qir-alliance.org/qat/QuickStart/running-qat/) section is missing qat examples showing usage of the revised circuit separation work, as described in the QAT DeveloperGuide: https://www.qir-alliance.org/qat/DeveloperGuide/LogicSeparation/

Create a docker image that makes it easy to run clang-format and clang-tidy

Currently, receptions are thrown. This should be changed by introducing the error logger into the structure.

CMake needs updating and corresponding documentation should be written.

At the moment, lit tests are disabled. Consider reintroducing.

Grouping is currently experimental and not part of the spec. As a more clear image of what is needed, the pass, the documentation and the specs need to be streamlined.

Version needs to be added to build for reproducibility purposes

To streamline naming in the spec and the code, we need to refactor the code such that entities called "Profile" are changed into "Target" where a target consists of a "profile" (the classical instruction set) and a quantum instruction set.

For demonstrating qat's capabilities in the QIR Book, users have to build qat from the source code every time they open the book in Binder or any other pre-built environment. It would be great if we could distribute the binaries, so the installation process would be easier.

Write documentation on:

1. Profiles
2. How to apply profiles

I've had qat produce qir under the base profile with --disable-grouping (teleport-base.txt) and without (teleport-chain-grouping.txt) for the simple teleport chain QIR attached (teleport.txt). The main issue is that in both base profile version array alias counting operations appear in the file. The QIR in teleport.txt was produced when compiling the Q# with <PackageReference Include="Microsoft.Quantum.Type1.Core" Version="0.18.2108157818-beta" IsTargetPackage="true" /> specified in the csproj file. If there is consideration that these instructions may be allowed under the base profile, please let me know!

teleport.txt
teleport-base.txt
teleport-chain-grouping.txt

Currently, QAT uses whatever default machine is set by the LLVM code. This is likely to be the machine triple from the machine on which QAT is running rather than the target hardware. To fix this, we should have the possibility of setting the target machine from the command line.

Current, flag emit-llvm list as --S instead of -S.

At the moment it is only possible to load a single component at any one point.

Currently, debug information gets stripped when QAT is transforming the IR. We need to update this such that debug information is preserverd.

When creating a new profile, a set of pipeline tuning options are generated. This allows for enabling/disabling loop unrolling. These should be parameterised.

This follows:

• a demonstration of "QIR passes" in Python by @LaurentAjdnik on Apr. 14, 2022
• a discussion during the "QIR²" community call on May 19, 2002

QAT includes/mimics/relies on LLVM passes but embeds them inside QAT-specific components.

LLVM passes can be provided as standalone libraries that can be applied with the opt tool.

Proposal: Initiate an ever-growing set of genuine and standalone LLVM passes dedicated to QIR analysis and transformation.

Notes:

• We might need a specific Github repository
• Some passes could be generic while others would be hardware-specific
• Optimization passes could universally do what some QDKs provide only for their specific environment: Removing duplicate gates, Merging redundant gates...
• Hardware-specific passes could include everything that's needed to compile towards specific backends
• Hardware-specific passes could be provided by the corresponding vendors

Currently the setup for developers are not described for OS X developers.

Hi,

It seems like the --always-inline flag doesn't always force inlining in the generated QIR. I ran the following command via qat:
./qat --always-inline --apply -S --profile base MagicStateDistillation-10X.ll > MagicStateDistillation-BaseProfile.10X.ll
on the attached file and received the following output in MagicStateDistillation-BaseProfile.10X.ll (I changed the ll files to text files to attach them to the issue). The entry point function in the output file, @Microsoft__Quantum__Samples__MeasureDistilledTAtDepth10InX__Interop, calls out to a helper function @Microsoft__Quantum__Samples__Distill__body.4.

MagicStateDistillation-10X.txt
MagicStateDistillation-BaseProfile.10X.txt

Let me know if I should try again with additional arguments to qat, or whether you need any more information.

Add caching to the static analyser.

We need a clear definition of what base profiles are.

We need a section describing the overall architecture of the system.

Add logger infrastructure to the rule factory to ensure that errors and warnings are propagated correctly as substitutions fail.

Qubits that are allocated and operated on, but never measured should be trimmed.

Consider cases where they are used in circuits where other qubits are measured such as CNOT

If a pattern is created with no children, the exit path is always returning true. Check whether this should always be the case. One suggestion is that the value should be an instance of llvm::User.

Currently, functions which are marked as noinline still gets inlined.

Refactor the examples organisation and consider getting rid of all Makefile in favour of either Bazel or some more appropriate build system

When replicating component (or adding the same passes several times), memory sanitation issues occur. This should be understood and fixed.

Possibly the "correct" way to deal with this is to do a more granular approach, translating __quantum__rt__array_get_element_ptr_1d int to a constant i8*. For discussion with the team. A good example is

    %array1 = call %Array* @__quantum__rt__qubit_allocate_array(i64 10)
    %0 = call i8* @__quantum__rt__array_get_element_ptr_1d(%Array* %array1, i64 7)
    %1 = bitcast i8* %0 to %Qubit**
    %qubit = load %Qubit*, %Qubit** %1, align 8
    ;;; call @__quantum__qis__h__body(%Qubit* %qubit)  < Note this instruction is missing

LLVM will optimise the two last instructions away even at O0 as they are not used. Consequently, the pattern fails.

The build instructions at https://github.com/qir-alliance/qat/blob/main/docs/src/UserGuide/BuildingLibrary.md#build-instructions-for-users and at https://qir-alliance.github.io/qat/UserGuide/QuickStart/ both list that to build QAT, one needs to start by running cd src/Passes from the root of the repo. Doing so results in an error, as there is no such folder in the repo currently.

There is a possibility for errors when eliminating branch blocks in case there is an order mismatch. Add asserts to ensure this is tested for.

Consider separating the functionality to annotate resource usage from the profile class to create a cleaner internal implementation.

The current approach may not work on multi path branches (conditional) as we may accidentally add the final path (contains qubit release) and we cannot make assumptions since optimisation may have rearranged everything. In this case, we should revert to the order they appear in the function.

LLVM offers a number of attributes for functions and/or their parameters. We should investigate which of these can be used to simplify the IR. For instance, it is expected that readonly and byval will help LLVM optimise memory management. The open question to be answered is whether, QAT can inject these for known standard functions to improve performance.

Currently QAT use old attributes as default in the spec definition (i.e. EntryPoint)

There should be a test suite for provider targets confirming that those IRs that we expect to work works and those we expect to fail, fails.

Followed the Bazelisk build instructions. Had to use a slightly modified command line because my default user folder has a space in it:

bazelisk --output_user_root="C:\Users\Default\bazelisk" build //qir/qat:qat --config msvc --config release

Fixed a variety of small environment setup issues, but then end up with this error:

bash.exe failed: error executing command
cd /d C:/users/default/bazelisk/a7tojsoq/execroot/microsoft
SET PATH=... 
SET RUNFILES_MANIFEST_ONLY=1

C:\Windows\system32\bash.exe -c source external/bazel_tools/tools/genrule/genrule-setup.sh; bazel-out/host/bin/qir/qat/VersionBuilder.exe bazel-out/host/bin/qir/qat/workspace.txt qir/qat/Version/Version.tpl.hpp bazel-out/x64_windows-fastbuild/bin/qir/qat/Version/Version.hpp
# Configuration: e79f7d451c97d5663ceb5bde06780c688e3255310be50fac34b57c1edb492a0c
# Execution platform: @local_config_platform//:host
LAUNCHER ERROR: Cannot open the binary to read launch data
LAUNCHER ERROR: Failed to parse launch info.
Target //qir/qat:qat failed to build

Just omitting the path for succinctness, can provide if necessary. Every file referenced in the bash command exists except the Version.hpp which I assume is the output. I'm on a relatively standard windows 10 home dev machine.

Any pointers to help find out what's going wrong?

Currently some tests fail on Mac M1 hardware due to incorrect configuration.

At the moment, the switch pattern only matches on the operand type, but not on its children.

We have previously made experimental support for Q# ND arrays. This part of the code needs refactor and improvement.

We need to introduce configuration files into qat to make it easier to configure.

This work item requires a re-design of the grouping pass to set out a longer term vision for management of loading program parameters, executing the program on the QPU and retrieving the corresponding results.

Currently, the position of the error is not recorded when internal class are detected during validation. This makes it harder to debug using the error messages.

We need a section on how to properly write C++ tests as part of contributing to the project.

Use weak pointers to capture allocation managers to ensure that no circular memory references occur.