wvlothuizen
commented
2 years ago moving constant folding and its consequences entirely to OpenQL
IIRC from a conversation with Jeroen, the constant folding was partly intended to allow simple libqasm users (e.g. a simulator) to have this functionality without having to implement anything locally.
The functions are part of the IR (the name, profile and return type are defined in ir->platform), but more information is often needed and there is no easy way to maintain consistency (ql/pass/opt/const_prop/detail/platfom_functions might be extended for that purpose).
Libqasm and OpenQL both have ideas on the presence of functions that support classical operations. Libqasm has defaults for them but OpenQL overrides those selectively when constructing a libqasm based cqasm reader. By construction, doing the latter blocks applying the old ones during constant folding in libqasm. So libqasm and OpenQL interfere in this respect and this needs a redesign. See the following quote from the code: Quoting from arch::cc::pass::gen::vq1asm::detail::codegen.h, especially see that last sentence:
/**
Handle expressions.
To understand how cQASM functions end up in the IR, please note that functions are handled during analyzing
cQASM, see 'AnalyzerHelper::analyze_function()'.
A default set of functions that only handle constant arguments is provided by libqasm, see
'register_into(resolver::FunctionTable &table)'. These functions add a constant node to the IR when called (and
fail if the arguments are not constant)
Some of these are overridden by OpenQL to allow use of non-constant arguments. This is a 2 step process, where
'convert_old_to_new(const compat::PlatformRef &old)' adds functions to ir->platform using 'add_function_type',
and 'ql::ir::cqasm:read()' then walks 'ir->platform->functions' and adds the functions using
'register_function()'. These functions add a 'cqv::Function' node to the IR (even if the arguments are constant,
so overriding a function defeats libqasm's constant removal for that function). */ A solution may be in:
separating the implementations of functions of libqasm and OpenQL
moving constant folding and its consequences entirely to OpenQL
making those functions 1st class citizens of the OpenQL IR
Somehow this set of functions is not a proper part of the IR now. More and more passes will need this list so standardization is required. And it needs to be at least a superset of what all OpenQL targets support. And then there needs to be pass for each target that checks and enforces the entry conditions of the code generator (which can have run-time equivalents, etc.). There maybe even functions to which calls are created by the compiler and that are not created because calls were found in a cqasm file; this certainly is true when you consider that there are multiple cqasm versions, but also when another language (e.g. OpenQASM) would be read by OpenQL. So the function list needs to be standardized as part of the IR of OpenQL; and we need to be able to distinguish such standard functions from regular functions.
Agreed. Functions need a proper redesign anyway when the ideas in https://github.com/QuTech-Delft/cQASM-spec/tree/95ee081c0910548b8201c510f88ebc89be9284e8 are implemented. This would also improve the user experience a lot, because currently gate decomposition works a lot like a function call, but otherwise user defined functions don't exist, so there is no way to reuse pieces of code