In https://github.com/QuTech-Delft/OpenQL/issues/419, support for parameterized gate decompositions was tracked. It was concluded that such support already exists and works, but is only meaningful if the parameter can somehow be consumed, either by supporting parameterized gates at the backend level, or by allowing the following type of decompositions to work (with a much longer if-chain in practice):
// Parameterized gate decompositions (test)
"_rx": {
"prototype": ["X:qubit", "L:int"],
"duration": @MW_DURATION@,
"decomposition": {
"into": [ // FIXME: makes no real sense, and currently fails in backend
"if (op(1) < 45) {",
" rx45 op(0)",
"} else {",
" rx90 op(0)",
"}"
]
}
The latter approach currently fails because the backend doesn't support constant expressions (e.g. 23 < 45), and that is the case because it was earlier decided that such support would be better offloaded to a separate pass, instead of polluting the backend (see https://github.com/QuTech-Delft/OpenQL/issues/424). Such a pass wouldn't only support paramerized instructions, but also adds generic support for constant expressions in other contexts.
wvlothuizen
commented
2 years ago
In https://github.com/QuTech-Delft/OpenQL/issues/419, support for parameterized gate decompositions was tracked. It was concluded that such support already exists and works, but is only meaningful if the parameter can somehow be consumed, either by supporting parameterized gates at the backend level, or by allowing the following type of decompositions to work (with a much longer if-chain in practice):
The latter approach currently fails because the backend doesn't support constant expressions (e.g.
23 < 45), and that is the case because it was earlier decided that such support would be better offloaded to a separate pass, instead of polluting the backend (see https://github.com/QuTech-Delft/OpenQL/issues/424). Such a pass wouldn't only support paramerized instructions, but also adds generic support for constant expressions in other contexts.