razvnane
commented
4 years ago * src/kernel.h: in the end, the check on validity of the qubit/creg parameters must go in again; it is part of the API interface; as I wrote, there is a difference between the number of those in the program and those in the platform and this becomes relevant when mapping; does the cqasmreader do any such checks?
it is part of the old API, which should be deprecated imo at a later point. qubits and cregs are platform-dependent parameters so they should be inputted in the backend. The mapping should read that information together with the topology etc...
cqasm probably has a check, but I haven't looked at it.
* src/passes.cc: we can have explicit writer passes where one wants but my experience is that writer passes (and report statistics passes) just before and just after a pass are very useful; so I propose to have the abstract runOnProgram method have a writer just before and just after it, with names as done now in report_qasm etc.; those could be enabled by standard pass local options; similarly for report_statistics
I have no preference. Either way works. Having it in this way though is more clearer for the user where is the reader/writer pass in case one wants to customize it and have his own reader/writer...
* src/passmanager.cc: is there a way in C++ (e.g. by a hidden entry point in each .cc file, or by a constructor called to initialize a global object; what is **init**?) to automatically register that the .cc file containing a new pass definition is present in the compiler; then we don't have to explicitly have a list of those in createPass
there should be an option like this, but i haven looked yet.
* src/passes.cc: the bump_unique_file_version is a once-only initialization of a string that is used to create unique report output file names for qasm and statistics; in the current system, the program's name is modified but in the new implementation this should be a separate name; see src/report.h
that code was intended as an example. We should modify it later, now I was just focusing on proof-of-concept.
* src/passes.cc: I didn't see yet that e.g. the scheduler has a private commute option (i.e. not present in other passes) and that its value can differ for each concrete scheduler pass (assuming that there are 2 of these)
did not get this point, but I also have not focused on the scheduler since it is entangled with the number of qubits, cregs, and cycle time... imo those should be parameters that can be set with options or in the backend read from the platform configuration file.
jvansomeren
Added methods to add passes and set options to passes. These need to be further implemented. Also, I disabled the unitary decomposition to speedup compilation until that is fixed. Some tests will fail as a consequence.