State synthesis for quantum devices #2291

annagrin · 2024-10-17T15:50:52Z

Synthesize state pointer for quantum devices:

SimulationState:

Add hasData API that returns true iff the vector data exists on the state or can be computed.
Add getKernelInfo API that returns optional kernel name and a list of arguments for the kernel that generated the state.

QuantumState:

Add QuantumState class that inherits from simulation state and keeps kernel information only.

ArgumentConversion:

Substitute state pointer argument with quake.get_state "callee.num_qubits_N" "callee.init_N" instruction.
Add callee.num_qubits_N and callee.init_N functions that are created from the callee code and compute allocation size and initialize the allocation, respectively.
Add a list of converters for the callees in ArgumentConverter.
Generate substitutions for modified callee functions, recursively.

Passes:

Add a post-synthesis ReplaceStateWithKernel pass that
- replaces quake.get_num_qubits instructions by a call to callee.num_qubits_N()
- replaces quake.init_state instructions by a call to callee.init_N()

Synthesis:

Collect all substitutions for the call tree at the synthesis time for quantum devices.

Tests:

Add fake quantum state and a test for quantum state argument conversion to test_argument_conversion
Add quake tests for ReplaceStateWithKernel pass
Add quake tests for ArgumentSynthesis pass with state pointer substitutions
Add targettests/execution/qvector_init_from_state.cpp test that runs for various quantum backends emulation

Notes

Currently state pointer synthesis is only supported for kernels implemented as operator() inside a struct.

TODO (in subsequent PRs)

c++ tests for quantum backend integration
Use cudaq::qkernel to support c-like kernels in state pointer synthesis
Tests for synthesis of vectors of pauli words (needs rework of pauli word support)
python tests for quantum platforms (needs support for new synthesis in python)

~~Requires: #2354~~

I, Ben Howe <[email protected]>, hereby add my Signed-off-by to this commit: 86681ef Signed-off-by: Ben Howe <[email protected]> Signed-off-by: Anna Gringauze <[email protected]>

Signed-off-by: Anna Gringauze <[email protected]>

…antum-device-state

Signed-off-by: Anna Gringauze <[email protected]>

lib/Optimizer/Transforms/StateInitialization.cpp

runtime/common/CMakeLists.txt

runtime/cudaq/algorithms/get_state.h

1tnguyen

LGTM 👍

Signed-off-by: Anna Gringauze <[email protected]>

…antum-device-state

schweitzpgi

Still reviewing...

include/cudaq/Optimizer/Builder/Intrinsics.h

include/cudaq/Optimizer/Transforms/Passes.td

schweitzpgi

Still reviewing...

lib/Optimizer/Transforms/StateInitialization.cpp

lib/Optimizer/Transforms/StateValidation.cpp

…antum-device-state

Signed-off-by: Anna Gringauze <[email protected]>

…ate-ops Signed-off-by: Anna Gringauze <[email protected]>

…antum-device-state Signed-off-by: Anna Gringauze <[email protected]>

Signed-off-by: Anna Gringauze <[email protected]>

…antum-device-state Signed-off-by: Anna Gringauze <[email protected]>

I, Anna Gringauze <[email protected]>, hereby add my Signed-off-by to this commit: 9563371 Signed-off-by: Anna Gringauze <[email protected]>

…antum-device-state Signed-off-by: Anna Gringauze <[email protected]>

schweitzpgi · 2025-01-23T00:21:18Z

include/cudaq/Optimizer/Dialect/Quake/QuakeOps.td

+    StrAttr:$numQubitsFuncName,
+    StrAttr:$initFuncName


Suggested change

StrAttr:$numQubitsFuncName,

StrAttr:$initFuncName

FlatSymbolRefAttr:$numQubitsFuncName,

FlatSymbolRefAttr:$initFuncName

If these are truly artifacts that shall be present in the IR, let's make them Symbol attrs.

If the signatures of those functions are changed by the synthesis, would this instruction get updated with symbols with new signatures during application of the substitution? I can try that and see if the synthesis works.

I don't believe that'll be an issue. That is, you can update the signature independently of the symbol.

schweitzpgi · 2025-01-23T00:22:36Z

include/cudaq/Optimizer/Dialect/Quake/QuakeOps.td

+  let arguments = (ins
+    StrAttr:$numQubitsFuncName,
+    StrAttr:$initFuncName
+  );
  let results = (outs cc_PointerType:$result);


We probably want to force this to be a ptr<state>, no?

Will do, thanks

schweitzpgi · 2025-01-23T00:24:02Z

include/cudaq/Optimizer/Transforms/Passes.h

+createArgumentSynthesisPass(const std::vector<std::string> &funcNames,
+                            const std::vector<std::string> &substitutions);


Why do we need this? ArrayRef should subsume rigid std::vector here. I don't think we need this overload?

std::vector<string> does not get auto-converted to ArrayRef<StringRef>... I can try ArrayRef<std::string> instead

schweitzpgi · 2025-01-23T00:27:15Z

runtime/common/ArgumentConversion.h

+    return calleeConverters;
+  }
+
+  std::pair<std::vector<std::string>, std::vector<std::string>>


Use SmallVector.

I think i tried and something went wrong, will try again

schweitzpgi · 2025-01-23T00:30:42Z

runtime/common/BaseRemoteRESTQPU.h

-        llvm::raw_string_ostream ss(substBuff);
-        ss << argCon.getSubstitutionModule();
-        mlir::SmallVector<mlir::StringRef> substs = {substBuff};
+        auto [kernels, substs] = argCon.collectAllSubstitutions();


Looks like you got in trouble here by moving the strings into another function, where they go out of scope and vanish.

Let's leave the string creation here, where it is. To change it might look a little nicer, but it is far less efficient. Instead of a single copy of the data, we're building vectors of copies of the data and passing those around. The LLVM Way (tm) is preferred in the compiler code.

The nested argument converters (for kernels used in get_state calls) have their new kernel names, created during state argument conversion, so I moved the kernel name storage to the ArgumentConverter for the kernel.

I thought about an alternative of having a special "storage" for the new names collection and passing that storage by reference to ArgumentConverter and its children, but that does not seem to solve the problem of efficiency of copying the name for the entry kernel. I appreciate any ideas here!

Let me try to be more clear.

The LLVM way to do this sort of thing is to build the string and/or vector data on the stack in the calling function. This will be reclaimed once the task we're performing completes.

For the called functions (the call tree below the "top" function where the data was built), we use the LLVM ADTs which are efficient lightweight wrappers around that data. This eliminates the use of heap memory, accidentally calling copy-constructors and destructors, etc. At the "leaf layer" where we create, say, MLIR IR, any data that must be interned is captured into the MLIRContext.

Why is it done this way? Because both LLVM and MLIR use a model of invariant pointers to refer to distinct artifacts in the overall representation. If we have an Op*, then that pointer value will never change. The Op may be logically replaced, by updating all references in the IR, but the Op itself will never be moved/copied someplace else in memory. This applies to Type values, string data, etc. Once it's in the IR, think of it as semi-permanent or congealed into a memory location, if you will. Because of all that, using STL containers and std::string is likely because the code isn't really structured in the spirit of the underlying LLVM model.

Of course this model imposes a bit of structure on how we write the code and implement things. It limits the types of refactoring we can do. But that's ok, because we can do it the LLVM Way, be efficient, and avoid bugs.

schweitzpgi · 2025-01-28T15:56:20Z

include/cudaq/Optimizer/Dialect/Quake/QuakeOps.td

+    It takes two kernel names as ASCIIZ string literals:
+      - "num_qubits" for determining the size of the allocation to initialize
+      - "init" for initializing the state the same way as the original kernel
+        passed to `cudaq::get_state`) as ASCIIZ string literal


Suggested change

passed to `cudaq::get_state`) as ASCIIZ string literal

passed to `cudaq::get_state`) as an ASCIIZ string literal

schweitzpgi · 2025-01-28T15:57:09Z

include/cudaq/Optimizer/Dialect/Quake/QuakeOps.td

+      - "init" for initializing the state the same way as the original kernel
+        passed to `cudaq::get_state`) as ASCIIZ string literal
+
+    And returns the quantum state of the original kernel passed to


Suggested change

And returns the quantum state of the original kernel passed to

This operation will return the quantum state of the original kernel passed to

schweitzpgi · 2025-01-28T15:59:19Z

include/cudaq/Optimizer/Dialect/Quake/QuakeOps.td

+        passed to `cudaq::get_state`) as ASCIIZ string literal
+
+    And returns the quantum state of the original kernel passed to
+    `cudaq::get_state`. The operation is replaced by calls to the kernels with


Suggested change

`cudaq::get_state`. The operation is replaced by calls to the kernels with

`cudaq::get_state`. The operation may be replaced by calls to a kernel, which will reproduce the specified state and whose name is provided

schweitzpgi · 2025-01-28T15:59:45Z

include/cudaq/Optimizer/Dialect/Quake/QuakeOps.td

+
+    And returns the quantum state of the original kernel passed to
+    `cudaq::get_state`. The operation is replaced by calls to the kernels with
+    the provided names in `ReplaceStateByKernel` pass.


Suggested change

the provided names in `ReplaceStateByKernel` pass.

by the `ReplaceStateByKernel` pass.

schweitzpgi · 2025-01-28T16:05:40Z

include/cudaq/Optimizer/Dialect/Quake/QuakeOps.td


    ```mlir
-      %0 = quake.get_state "callee" : !cc.ptr<!cc.state>
+      %0 = quake.get_state "num_qubits" "init" : !cc.ptr<!cc.state>


I think these two parameters need to be an IntegerAttr and a Symbol. The syntax ought to look like

quake.get_state @init_artifact, <n> (attributes { ... })?

We don't even need the type, since I don't think it can be anything other that !cc.ptr<!state>, right?

schweitzpgi · 2025-01-28T16:12:45Z

include/cudaq/Optimizer/Transforms/Passes.td

+    "Replace `quake.init_state` instructions with call to the kernel generating the state";
+  let description = [{
+    Argument synthesis for state pointers for quantum devices substitutes state
+    argument by a new state created from `__nvqpp_cudaq_state_get` intrinsic, which


Suggested change

argument by a new state created from `__nvqpp_cudaq_state_get` intrinsic, which

a new state created from the `__nvqpp_cudaq_state_get` intrinsic for the state argument.

schweitzpgi · 2025-01-28T16:14:17Z

include/cudaq/Optimizer/Transforms/Passes.td

+  let description = [{
+    Argument synthesis for state pointers for quantum devices substitutes state
+    argument by a new state created from `__nvqpp_cudaq_state_get` intrinsic, which
+    in turn accepts the name for the synthesized kernel that generated the state.


Suggested change

in turn accepts the name for the synthesized kernel that generated the state.

The `__nvqpp_cudaq_state_get` intrinsic accepts the symbol for the synthesized kernel that generated the state.

schweitzpgi · 2025-01-28T16:17:02Z

include/cudaq/Optimizer/Transforms/Passes.td

+
+    This optimization completes the replacement of `quake.init_state` instruction by:
+
+    - Replace `quake.init_state` by a call that `get_state` call refers to.


Suggested change

- Replace `quake.init_state` by a call that `get_state` call refers to.

- Replacing `quake.init_state` by a call to a kernel to construct the state. e.g., The `cudaq::get_state` call refers to the result of a specific quantum kernel being invoked with a set of parameters.

schweitzpgi · 2025-01-28T16:19:00Z

include/cudaq/Optimizer/Transforms/Passes.td

+    This optimization completes the replacement of `quake.init_state` instruction by:
+
+    - Replace `quake.init_state` by a call that `get_state` call refers to.
+    - Remove all unneeded instructions.


Suggested change

- Remove all unneeded instructions.

- Remove any unneeded Ops.

I think we only really need to remove Ops that have side-effects. Any that are pure and unused will just go away with the next DCE that runs.

schweitzpgi · 2025-01-28T16:21:01Z

lib/Optimizer/Transforms/ArgumentSynthesis.cpp

@@ -163,3 +163,12 @@ cudaq::opt::createArgumentSynthesisPass(ArrayRef<StringRef> funcNames,
  return std::make_unique<ArgumentSynthesisPass>(
      ArgumentSynthesisOptions{pairs});
 }
+
+std::unique_ptr<mlir::Pass> cudaq::opt::createArgumentSynthesisPass(
+    const std::vector<std::string> &funcNames,


As discussed, we should see if we can't get rid of this overload and use the original function with the LLVM ADT signature.

schweitzpgi · 2025-01-28T18:38:16Z

runtime/cudaq/algorithms/get_state.h

+  if (!cudaq::get_quake_by_name(cudaq::getKernelName(kernel), false).empty()) {
+    return state(new QuantumState(std::forward<QuantumKernel>(kernel),
+                                  std::forward<Args>(args)...));
+  } else {


https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return

runtime/cudaq/qis/quantum_state.cpp

schweitzpgi · 2025-01-28T18:50:26Z

runtime/test/FakeSimulationState.h

@@ -21,7 +21,7 @@ class FakeSimulationState : public cudaq::SimulationState {
  virtual std::unique_ptr<SimulationState>
  createFromSizeAndPtr(std::size_t size, void *data,
                       std::size_t dataType) override {
-    std::runtime_error("Not implemented");
+    throw std::runtime_error("Not implemented");
    return std::make_unique<FakeSimulationState>(size, data);


The return is never reached, right?

schweitzpgi · 2025-01-28T18:53:33Z

runtime/test/test_argument_conversion.cpp

-                  "Substitution module:\n"
-               << ab.getSubstitutionModule() << '\n';
+  // Dump the modified source module
+  llvm::outs() << "Source module (after):\n" << *mod << '\n';


Is this dumping the same thing? It looks like it was dumping the substitution module but now is dumping the module receiving the substitutions?

Since this is testing argument conversions, we must care about building the substitutions properly. The code into which they are applied is only interesting at the point of argument synthesis, no?

amccaskey · 2025-01-28T18:57:52Z

runtime/cudaq/qis/quantum_state.h

+// The state is represented by a quantum kernel.
+// Quantum state contains all the information we need to replicate a
+// call to kernel that created the state.
+class QuantumState : public cudaq::SimulationState {


I don't think something like this should be in the qis folder. Would be best to move it to somewhere in the platform folder, I'd also suggest to name it something like RemoteQPUSimulationState.

As-is, QuantumState is very generic and putting it in the qis folder (in the public cudaq namespace) makes one think it is more of a language-level thing, when really its an internal implementation detail.

schweitzpgi · 2025-01-28T20:44:02Z

runtime/common/ArgumentConversion.cpp

+  auto argPos = initFunc.getArguments().size();
+
+  // Detect errors in kernel passed to get_state.
+  std::function<void(Block &)> processInner = [&](Block &block) {


Suggested change

std::function<void(Block &)> processInner = [&](Block &block) {

auto processInner = [&](Block &block) {

schweitzpgi · 2025-01-28T20:44:24Z

runtime/common/ArgumentConversion.cpp

+      for (auto &region : op.getRegions()) {
+        for (auto &b : region)
+          processInner(b);
+      }


Suggested change

for (auto &region : op.getRegions()) {

for (auto &b : region)

processInner(b);

}

for (auto &region : op.getRegions())

for (auto &b : region)

processInner(b);

schweitzpgi · 2025-01-28T20:45:00Z

runtime/common/ArgumentConversion.cpp

+        processInner(b);
+
+  // Process outer block to initialize the allocation passed as an argument.
+  std::function<void(Block &)> process = [&](Block &block) {


Suggested change

std::function<void(Block &)> process = [&](Block &block) {

auto process = [&](Block &block) {

schweitzpgi · 2025-01-28T20:47:29Z

runtime/common/ArgumentConversion.cpp

@@ -99,12 +99,245 @@ static Value genConstant(OpBuilder &, cudaq::cc::StructType, void *,
 static Value genConstant(OpBuilder &, cudaq::cc::ArrayType, void *,
                         ModuleOp substMod, llvm::DataLayout &);

+/// Create callee.init_N that initializes the state
+/// Callee:
+/// func.func @__nvqpp__mlirgen__callee(%arg0: i64) {


Is callee supposed to be the kernel that is captured by get_state?

schweitzpgi · 2025-01-28T20:57:37Z

runtime/common/ArgumentConversion.cpp

+
+  auto argTypes = calleeFunc.getArgumentTypes();
+  auto retTy = quake::VeqType::getUnsized(ctx);
+  auto funcTy = FunctionType::get(ctx, argTypes, TypeRange{retTy});


Why are we returning qubit references? From the above comments, it looks like the references are passed into this new function as an argument.

Returning a set of new references violates the assumption that the entry-point kernel is strictly responsible for creating all the (non-temporary) qubits for the circuit. (In other words, other passes will be broken, if this rule is not followed.)

schweitzpgi · 2025-01-28T21:15:04Z

runtime/cudaq/algorithms/get_state.h

+    throw std::runtime_error(
+        "cudaq::state* argument synthesis is not supported for quantum hardware"
+        "for c-like functions, use class kernels instead");
+  }
 #endif


Suggested change

#endif

#else

and wrap the return in the else conditional block...

schweitzpgi · 2025-01-28T21:17:37Z

runtime/test/FakeQuantumState.h

+#include "cudaq/qis/state.h"
+#include <cassert>
+#include <memory>
+


Suggested change

nit

schweitzpgi · 2025-01-28T21:18:36Z

runtime/test/test_argument_conversion.cpp

+  {
+    auto kernel = "init";
+    auto kernelCode =
+        ""


Suggested change

""

schweitzpgi · 2025-01-28T21:18:58Z

runtime/test/test_argument_conversion.cpp

+  {
+    auto kernel = "init";
+    auto kernelCode =
+        ""


Suggested change

""

schweitzpgi · 2025-01-28T21:24:18Z

runtime/common/ArgumentConversion.cpp

+        builder.getStringAttr(initKernelName));
+  }
+
+  TODO("cudaq::state* argument synthesis for quantum hardware for c functions");


Why doesn't this use cudaq::qkernel? That's the vehicle for capturing quantum kernels in general-purpose C++ code contexts. Since cudaq::get_state() may appear anywhere, I don't understand how we know what kernel is being captured.

There is the additional issue of captured arguments as well...

schweitzpgi · 2025-01-28T21:54:47Z

I'm going to have to experiment with this on my machine. I'm not sure I get what's going on... For example,

int main() {
  // This is not quantum code and will never be seen by our compiler.
  ...
  KernelA a;  // our compiler sees KernelA's call operator.
  a(arg0, arg1, ... argN); // but not this call
  ...
  auto state1 = cudaq::get_state(a);   // is this ok per the spec?
  ...
  // f is a plain old function marked with __qpu__, so compiler sees it
  ...
  auto state2 = cudaq::get_state(f, frg0, frg1, ... frgN);  // I think this must be supported
  ....
  KernelB b;  // our compiler sees KernelB's call operator
  b(brg0, brg1, ..., state1, state2); // but not this call
  ...
}

So our implementation must capture the context to fully recreate the kernel launches of a and f so they can be replayed by the kernel launch of b. But we're not using qkernel which is the piece that captures a and f in main. I'm not sure how/if the state capture of a would work since the arguments aren't present. (Hopefully, that's not a legit case.)

If we focus on f here, and we were to capture the kernel in a qkernel then we can also capture the args in the get_state calls argument list.

Now "argument synthesis" is sort of a misnomer at this point. KernelB takes 2 cudaq::state* arguments, but there is nothing to synthesize (explicitly in terms of data constants) and substitute into the body here. In fact, the state* arguments are dead. The quake.init_state Ops that use them in the original code can be rewritten into device-only calls to KernelA'::operator() and f' which are clones of KernelA::operator() and f with extra argument(s) stuck on which are the veq (or ref) quake.alloca's from KernelB being passed in and which replace the corresponding quake.alloca operations in the called (now) device-only kernel (prime variants).

So unless I am missing something, it seems like this can be implemented without argument synthesis and as a standalone compiler pass, no? (Argument conversion would need to know that the cudaq::state* are just getting dropped on the floor, I guess.)

In a bit of a cosmic twist, it is actually f' and the arguments gathered in the cudaq::get_state there that has to undergo the full argument synthesis. On all its original arguments, at any rate. The qubit references that are added would be ignored, but the argument conversion + synthesis cleanly handles substitutions of arbitrary arguments.

test/Quake/arg_subst-5.txt

schweitzpgi · 2025-01-29T23:29:14Z

test/Quake/arg_subst_func.qke

+  return
+}
+
+func.func @init(%arg0: i64, %arg1: !quake.veq<?>) -> !quake.veq<?> {


For these init kernels, the qubit vector is passed as references, which means the qubits passed in will be changed by the function in-place (or remain unchanged if unreferenced, I suppose). I don't think returning that same set of qubit references is needed.

schweitzpgi · 2025-01-29T23:32:05Z

test/Quake/arg_subst_func.qke

+  return %arg1 : !quake.veq<?>
+}
+
+func.func @num_qubits(%arg0: i64) -> i64 {


When we get to the phase of building the substitutions, we should know the number of qubits as a constant, right?

schweitzpgi · 2025-01-30T01:07:38Z

runtime/test/FakeSimulationState.h

@@ -21,7 +21,7 @@ class FakeSimulationState : public cudaq::SimulationState {
  virtual std::unique_ptr<SimulationState>


This header file and FakeQuantumState.h are really just scaffolding for the test and aren't included anywhere else. We could get rid of these .h files and move the code into the file test_argument_conversion.cpp.

In fact, most of the code for these two classes is the same or very similar and could be shared or templated.

annagrin requested review from schweitzpgi and 1tnguyen October 17, 2024 15:53

annagrin force-pushed the quantum-device-state branch from 623ab4b to 4517712 Compare October 17, 2024 21:27

bmhowe23 and others added 4 commits October 17, 2024 14:33

DCO Remediation Commit for Ben Howe <[email protected]>

ac01dd1

I, Ben Howe <[email protected]>, hereby add my Signed-off-by to this commit: 86681ef Signed-off-by: Ben Howe <[email protected]> Signed-off-by: Anna Gringauze <[email protected]>

State pointer synthesis for quantum hardware

21a87c1

Signed-off-by: Anna Gringauze <[email protected]>

Merge with main

3fc56de

Signed-off-by: Anna Gringauze <[email protected]>

Merge with main

7969a75

Signed-off-by: Anna Gringauze <[email protected]>

annagrin force-pushed the quantum-device-state branch from 4517712 to 7969a75 Compare October 17, 2024 21:38

annagrin added 3 commits October 17, 2024 15:24

Fix test failure on anyon platform

755d0d1

Signed-off-by: Anna Gringauze <[email protected]>

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into qu…

dc5e77e

…antum-device-state

Make StateInitialization a funcOp pass

382bc99

Signed-off-by: Anna Gringauze <[email protected]>

1tnguyen reviewed Oct 18, 2024

View reviewed changes

lib/Optimizer/Transforms/StateInitialization.cpp Outdated Show resolved Hide resolved

1tnguyen reviewed Oct 18, 2024

View reviewed changes

runtime/common/CMakeLists.txt Outdated Show resolved Hide resolved

1tnguyen reviewed Oct 18, 2024

View reviewed changes

runtime/cudaq/algorithms/get_state.h Show resolved Hide resolved

1tnguyen approved these changes Oct 18, 2024

View reviewed changes

annagrin added 2 commits October 18, 2024 11:09

Fix issues and tests for the rest of quantum architectures

d3a05d4

Signed-off-by: Anna Gringauze <[email protected]>

Merge with main

ac151f2

Signed-off-by: Anna Gringauze <[email protected]>

annagrin mentioned this pull request Oct 18, 2024

New launch kernel is not invoked for python #2299

Open

4 tasks

annagrin added 2 commits October 18, 2024 15:48

Fix failing quantinuum state prep tests

51ef054

Signed-off-by: Anna Gringauze <[email protected]>

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into qu…

0cdf3e9

…antum-device-state

schweitzpgi reviewed Oct 21, 2024

View reviewed changes

lib/Optimizer/Transforms/StateInitialization.cpp Outdated Show resolved Hide resolved

lib/Optimizer/Transforms/StateInitialization.cpp Outdated Show resolved Hide resolved

lib/Optimizer/Transforms/StateInitialization.cpp Outdated Show resolved Hide resolved

schweitzpgi reviewed Oct 21, 2024

View reviewed changes

annagrin added 7 commits October 21, 2024 11:00

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into qu…

5307aa4

…antum-device-state

Address CR comments

a7f5387

Signed-off-by: Anna Gringauze <[email protected]>

Merge with main

eb8db13

Signed-off-by: Anna Gringauze <[email protected]>

Format

9f0937f

Signed-off-by: Anna Gringauze <[email protected]>

Fix failing test

2f3a623

Signed-off-by: Anna Gringauze <[email protected]>

Format

b381350

Signed-off-by: Anna Gringauze <[email protected]>

Format

dc87ca4

Signed-off-by: Anna Gringauze <[email protected]>

Add printing in failing tests

074c60f

Signed-off-by: Anna Gringauze <[email protected]>

annagrin marked this pull request as draft November 5, 2024 18:03

annagrin added 12 commits November 12, 2024 10:06

Fix failing tests

310f6ca

Signed-off-by: Anna Gringauze <[email protected]>

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into st…

f0176ae

…ate-ops Signed-off-by: Anna Gringauze <[email protected]>

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into qu…

d17fa6d

…antum-device-state Signed-off-by: Anna Gringauze <[email protected]>

Merge with state-ops

3425182

Signed-off-by: Anna Gringauze <[email protected]>

Add description for new algorithm for state syntesis

6fdccba

Signed-off-by: Anna Gringauze <[email protected]>

Merge with main

fc5e154

Signed-off-by: Anna Gringauze <[email protected]>

Fix tests

1dfa805

Signed-off-by: Anna Gringauze <[email protected]>

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into qu…

b67fc88

…antum-device-state Signed-off-by: Anna Gringauze <[email protected]>

Make intermediate IR legal by separating allocs

9563371

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into qu…

f32b066

…antum-device-state Signed-off-by: Anna Gringauze <[email protected]>

DCO Remediation Commit for Anna Gringauze <[email protected]>

008e8c1

I, Anna Gringauze <[email protected]>, hereby add my Signed-off-by to this commit: 9563371 Signed-off-by: Anna Gringauze <[email protected]>

Merge branch 'main' of https://github.com/NVIDIA/cuda-quantum into qu…

84a4369

…antum-device-state Signed-off-by: Anna Gringauze <[email protected]>

annagrin marked this pull request as ready for review January 22, 2025 17:37

annagrin requested a review from schweitzpgi January 22, 2025 17:37

schweitzpgi reviewed Jan 23, 2025

View reviewed changes

schweitzpgi reviewed Jan 28, 2025

View reviewed changes

runtime/cudaq/qis/quantum_state.cpp Show resolved Hide resolved

schweitzpgi reviewed Jan 28, 2025

View reviewed changes

amccaskey reviewed Jan 28, 2025

View reviewed changes

schweitzpgi reviewed Jan 28, 2025

View reviewed changes

schweitzpgi reviewed Jan 29, 2025

View reviewed changes

test/Quake/arg_subst-5.txt Show resolved Hide resolved

schweitzpgi reviewed Jan 29, 2025

View reviewed changes

schweitzpgi reviewed Jan 30, 2025

View reviewed changes

		createArgumentSynthesisPass(const std::vector<std::string> &funcNames,
		const std::vector<std::string> &substitutions);

	passed to `cudaq::get_state`) as ASCIIZ string literal
	passed to `cudaq::get_state`) as an ASCIIZ string literal

	And returns the quantum state of the original kernel passed to
	This operation will return the quantum state of the original kernel passed to

	`cudaq::get_state`. The operation is replaced by calls to the kernels with
	`cudaq::get_state`. The operation may be replaced by calls to a kernel, which will reproduce the specified state and whose name is provided

	the provided names in `ReplaceStateByKernel` pass.
	by the `ReplaceStateByKernel` pass.

	argument by a new state created from `__nvqpp_cudaq_state_get` intrinsic, which
	a new state created from the `__nvqpp_cudaq_state_get` intrinsic for the state argument.

	in turn accepts the name for the synthesized kernel that generated the state.
	The `__nvqpp_cudaq_state_get` intrinsic accepts the symbol for the synthesized kernel that generated the state.


		This optimization completes the replacement of `quake.init_state` instruction by:

		- Replace `quake.init_state` by a call that `get_state` call refers to.

	- Replace `quake.init_state` by a call that `get_state` call refers to.
	- Replacing `quake.init_state` by a call to a kernel to construct the state. e.g., The `cudaq::get_state` call refers to the result of a specific quantum kernel being invoked with a set of parameters.

	- Remove all unneeded instructions.
	- Remove any unneeded Ops.

	std::function<void(Block &)> processInner = [&](Block &block) {
	auto processInner = [&](Block &block) {

	std::function<void(Block &)> process = [&](Block &block) {
	auto process = [&](Block &block) {

		@@ -21,7 +21,7 @@ class FakeSimulationState : public cudaq::SimulationState {
		virtual std::unique_ptr<SimulationState>

State synthesis for quantum devices #2291

Are you sure you want to change the base?

State synthesis for quantum devices #2291

Conversation

annagrin commented Oct 17, 2024 • edited Loading

Synthesize state pointer for quantum devices:

SimulationState:

QuantumState:

ArgumentConversion:

Passes:

Synthesis:

Tests:

Notes

TODO (in subsequent PRs)

1tnguyen left a comment

Choose a reason for hiding this comment

schweitzpgi left a comment

Choose a reason for hiding this comment

schweitzpgi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annagrin Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

schweitzpgi Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

schweitzpgi commented Jan 28, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annagrin commented Oct 17, 2024 •

edited

Loading

annagrin Jan 23, 2025 •

edited

Loading

schweitzpgi Jan 23, 2025 •

edited

Loading

schweitzpgi commented Jan 28, 2025 •

edited

Loading