New launch kernel for python

[annagrin]

Description

New launch kernel for python

[annagrin]

@amccaskey @schweitzpgi I found this way of creating a context instead of passing it as an argument in an ArgWrapper - do you think this makes sense? If yes, I can simplify the code a bit and do the same for the remote simulator.

[amccaskey]

from the test failure, looks like you'll need to add

  registerLLVMDialectTranslation(*context);

here. See runtime/common/RuntimeMLIR.cpp:90

[amccaskey]

If Eric is ok with this then I think its a fine way to remove the need for passing ModuleOp+Context all the way through launching the kernel.

[schweitzpgi]

I feel like we're trying to coerce the Module and related MLIRContext to stick around even though they are going out of scope someplace. After spending a bit of time reading the code, it's not clear at all still.

pyAltLaunchKernel is getting a raw mlir::ModuleOp passed to it, which it uses. extractQuakeCodeAndContext (in REST QPU) is constructing its own MLIRContext, which it appears is trying to be a singleton instance. It's not entirely clear how this singleton would be the same one the ModuleOp used. I'm also not clear why we need a singleton MLIRContext. Since Python is itself multithreaded, that seems like a bottleneck and/or potential problem.

If we created mlir::ModuleOp instances and saved them in std::shared_ptr, I believe pybind11 would autogenerate the "right" code for us such that Python's reference counting would work with C++ shared ptr reference counting so that the Module and its context don't get deconstructed along the way.

[annagrin]

@amccaskey @schweitzpgi here is where I no longer pass the module to PyRemoteRESTQPU.cpp