oqc-community / qat

QAT is a quantum compiler and runtime focused on low-level, just-above-driver integration.
Other
49 stars 11 forks source link

[EXPERIMENTAL] Static `DeviceUpdate` instructions #256

Closed hamidelmaazouz closed 1 week ago

hamidelmaazouz commented 1 week ago

A static DeviceUpdate is one that updates an attribute on a target with a value that's known at compile time.

For example DeviceUpdate(some_channel, "scale", 1) simply assigns 1 to the attribute scale on target some_channel. But how come people use this version instead of simply saying some_channel.scale = 1 ?

In fact, the legacy code processes DeviceUpdates with a structure called DeviceInjector not only to "inject" (i.e. assign at runtime) but to "revert" any previous assignment(s) at "some aftermath" (*). It's the injection + reversion guarantee that appeals to people more than the direct way. Therefore DeviceUpdate(some_channel, "scale", 1) is roughly equivalent to sth like:

try:
    old_scale = some_channel.scale
    some_channel.scale = 1
finally:
    some_channel.scale = old_scale

or via some mechanism based on Python contexts.

Legacy code w/r to SweepIterator and DeviceInjectors worked fine because the (QAT IR) programs were simple basic blocks. In light of the recent efforts to bring control flow, analysis of these programs become (semantically) intractable. Therefore the problem being raised here is more on what static DeviceUpdate instructions mean globally for the QAT IR program and in awareness of control flow. Here are a few claims:

  1. While they are perfectly valid instructions, people use static DeviceUpdates (only) to benefit from the assignment + reversion process described above (*).
  2. Programmers writing QAT IR are likely unaware that the position of a static DeviceUpdate among other instructions is ultimately important.
  3. Static DeviceUpdates can ultimately influence codegen. Pulse evaluation at compile time is one typical effect.

This PR only describes a peculiar case of DeviceUpdate in QAT IR and does not provide a definite solution. The workaround implemented in this PR assumes the claims laid out above. Here's what it contributes: