search

QuTech-Delft / OpenQL

OpenQL: A Portable Quantum Programming Framework for Quantum Accelerators. https://dl.acm.org/doi/10.1145/3474222
https://openql.readthedocs.io
Other
100 stars 44 forks source link

new-IR support in CC backend #433

Closed wvlothuizen closed 2 years ago

wvlothuizen commented 2 years ago

This PR changes the CC backend by using the new IR instead of the old one. It now also supports features of the new IR like structured control flow.

While implementing, a few small changes were made to the core of OpenQL to fix some small issues and ease debugging. Additionally, some comments were added.

This PR supersedes #425, and adds much improved handling of cQASM functions to that

wvlothuizen commented 2 years ago

Somehow Travis has come to life again, probably because it is enabled on QuTech-Delft. Although it doesn't seem to always fail, it does now on https://github.com/QE-Lab/eQASM_Assembler.git, which hasn't been a part of this project for quite some time.

Since the .travis.yml configuration file is outdated, and superseded by Github actions anyway, it will be deleted

jvansomeren commented 2 years ago

What was your use case? Why did you add this test?

So for you a sufficiently high value would work as well. Or we take this test here out and put it at those places where the decomposition is actually done. And use the ignore_schedule flag.

That an instruction can have a duration and a decomposition serves the purpose to treat it as a primitive until the decomposition is done. E.g. scheduled, optimized, and mapped.

Groet,

Hans van Someren

Op 13 apr. 2022 om 22:45 heeft Wouter Vlothuizen @.***> het volgende geschreven:



@wvlothuizen commented on this pull request.

In src/ql/ir/old_to_new.cchttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_QuTech-2DDelft_OpenQL_pull_433-23discussion-5Fr849885057&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=m0y0dhwAHwZuMz4pmwiG4Vt2xNV1PH-iJVHEZ9YHJ4w&s=G4T43yFxVgOXQdO7JDwQ1dgBxorBpa-kLMkUIY6W5RA&e=:

@@ -229,14 +231,16 @@ static void parse_decomposition_rule( "expansions" ); }

  • utils::UInt decomp_duration = get_duration_of_block(rule_ir->program->blocks[0]);
  • if (decomp_duration > ityp->duration) {
  • QL_USER_ERROR(
  • "in " << description.str() << ": the duration of the schedule of " <<
  • "the decomposition (" << decomp_duration << ") cannot be longer " <<
  • "than the duration of the to-be-decomposed instruction (" <<
  • ityp->duration << ")"
  • );
  • if (ityp->duration > 0) { // 0 implies that durations are just added up, requires scheduling after decomposition

The test is part of function

/**

, a static helper for the new-style decompositions.

ityp->duration is taken from the duration field of the instruction in the JSON platform file.

When decompositions are intended to be used pre-scheduling, it is quite inconvenient to be forced to specify some duration. Specifying some 'large' number would work, but the trouble I have with that is that you then get into the situation where - depending on context - numbers are meaningful or not, and the context may be difficult to tell. A value that explicitly triggers special treatment is much more future-proof in my opinion, and 0 seems to be a safe value.

— Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_QuTech-2DDelft_OpenQL_pull_433-23discussion-5Fr849885057&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=m0y0dhwAHwZuMz4pmwiG4Vt2xNV1PH-iJVHEZ9YHJ4w&s=G4T43yFxVgOXQdO7JDwQ1dgBxorBpa-kLMkUIY6W5RA&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AEDTBNSZJKQJWDXEI5NTINTVE4XAHANCNFSM5QC7K6TA&d=DwMCaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=kNdT9ewT6pQdYFkBLR_5-ZqsrSTk7k5Hdd7MSC_Vnzg&m=m0y0dhwAHwZuMz4pmwiG4Vt2xNV1PH-iJVHEZ9YHJ4w&s=ifcDdO7c0zppi9Mx-ldhwp7a6SCesqRgRcnwlDO6mpM&e=. You are receiving this because your review was requested.Message ID: @.***>

jvansomeren commented 2 years ago

I'm still not confident with setting the instruction's duration to 0 to avoid getting the error. See my remark on that e.g. the measure is seen as a primitive before the decomposition is done and then needs a duration with a value that is approximately its real value, so that optimizers can judge what is more optimal; a duration of 0 means e.g. that in scheduling the chain of instructions with the measurement is not critical. Note that 'scheduling' is not rcscheduling but using the depgraph as a representation of the circuit which takes durations and dependences into account, as e.g. the mapper does. So getting the error is ok, not getting the error when the duration is 0, is also ok, but the means to not get the error by setting the duration to 0 is not ok for me. I'm looking for a solution in which the duration can be approximately 800 and you still wouldn't get the error because the decomposition is done before scheduling. I'm inclined to move the test to where the decomposition is really done. Also the test now is not sufficient because the decomposition may still lead to a failure when the resource use pattern of the substituted result is not matching that of the key gate.

wvlothuizen commented 2 years ago

@jvansomeren test now pass