OpenQL in its current shape relies on libqasm for constant folding.
Wouter is adding constant folding passes to OpenQL for expressions of which the IR allows them to be non-constant.
When more and more optimization passes are added, and when we would replace the configuration-based target specification by a cQASM include file / include-path based target specification, more opportunities for constant folding are introduced for which it is hard to impossible to guarantee that libqasm can constant fold them.
For this fields in the IR that are literal now (assuming them to be always constant) need to be updated to be general expressions, and passes relying on those being constant need to add constant folding just before their execution plus a check that the fields that they rely on to be constant, are indeed constant.
Now it seems far-fetched to make all literal IR fields general expressions, certainly those of types such as string and JSON.
Examples of fields in the IR that may be dependent on complicated expressions based on constant variables and target configuration conditions and that may become constant later in OpenQL than already in libqasm are:
OpenQL in its current shape relies on libqasm for constant folding. Wouter is adding constant folding passes to OpenQL for expressions of which the IR allows them to be non-constant. When more and more optimization passes are added, and when we would replace the configuration-based target specification by a cQASM include file / include-path based target specification, more opportunities for constant folding are introduced for which it is hard to impossible to guarantee that libqasm can constant fold them. For this fields in the IR that are literal now (assuming them to be always constant) need to be updated to be general expressions, and passes relying on those being constant need to add constant folding just before their execution plus a check that the fields that they rely on to be constant, are indeed constant. Now it seems far-fetched to make all literal IR fields general expressions, certainly those of types such as string and JSON. Examples of fields in the IR that may be dependent on complicated expressions based on constant variables and target configuration conditions and that may become constant later in OpenQL than already in libqasm are: