-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow construction from module and specific entry point name #5
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -77,6 +77,17 @@ XaccQuantum::~XaccQuantum() | |
xacc::Finalize(); | ||
} | ||
|
||
//---------------------------------------------------------------------------// | ||
/*! | ||
* Update the XACC accelerator and shot count. | ||
*/ | ||
void XaccQuantum::set_accelerator_and_shots( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be done at initialization time (which the constructor does) rather than at some arbitrary point after construction (where it could be in an unspecified state, like in the middle of a calculation). There shouldn't be any need for delayed partial initialization (bad practice in C++); can you explain the use case? Also please remember to run clang-format. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added this because Details (if you're interested)To see this in action, you can add this:$ git diff
diff --git a/app/qir-xacc.cc b/app/qir-xacc.cc
index 383fb6f..2bb6156 100644
--- a/app/qir-xacc.cc
+++ b/app/qir-xacc.cc
@@ -36,6 +36,11 @@ void run(std::string const& filename,
// Load the input
Executor execute{Module{filename}};
+ {
+ XaccQuantum xacc_temp(std::cout, accel_name, num_shots);
+ (void)xacc_temp;
+ }
+
// Set up XACC
XaccQuantum xacc(std::cout, accel_name, num_shots);
std::unique_ptr<RuntimeInterface> rt; Then, when running a trivial example:
I just opened this XACC PR to fix this problem for the sake of future QIR-EE users: ORNL-QCI/xacc#63. I removed this setter from this PR, but I will keep it in my fork because I do not want to re-do There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All right, makes sense since xacc has singletons. I'd prefer that we hide that kind of bad behavior in our implementation: for example, we could make a private helper class that cleanly manages XACC cleanup/teardown and would be called in the constructor/destructor. It's probably not a bad idea to do that anyway, since we've got this object oriented facade built on top of a singleton class: creating two different XaccQuantum classes simultaneously would wreak all sorts of havoc. |
||
std::string const& accel_name, size_type shots) { | ||
accelerator_ = xacc::getAccelerator(accel_name); | ||
QIREE_VALIDATE(accelerator_, << "failed to create accelerator"); | ||
accelerator_->updateConfiguration({{"shots", static_cast<int>(shots)}}); | ||
} | ||
|
||
//---------------------------------------------------------------------------// | ||
/*! | ||
* Prepare to build a quantum circuit for an entry point. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't QIR require a function to be specified as an entry point? or is this for the case where you have more than one entry point in a QIR file (and is that legal?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly, yeah. Sometimes the Qwerty runtime can produce a QIR module with multiple entry points.
I couldn't anywhere that the spec says that multiple entry points are allowed, but it doesn't seem to say that only one entry point is allowed either.
I learned this was possible from reading the qir-runner source code: 1, 2. The tl;dr is that if there is one entry point, qir-runner uses it, but otherwise they require specifying the name of the entry point to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, there's already a similar constructor overload that takes an entrypoint name, just with a filename instead of an
llvm::Module
:qiree/src/qiree/Module.cc
Line 129 in 9c1ff4c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, and I forgot about that function! I wonder if we need to restructure so that the
Executor::operator()
takes the entry point function name since one module has to be correspond exactly to a single executor, and if we have multiple entry points in one module it would be better not to have to recreate the module each time?