Following the discussion on May 16, we would like to have a special kind of symbol, which is undefined.
Motivation: Symbolic analysis is crucial to DaCe and transformations. However, not every data container needs to have a concrete symbolic value for a program to function (nor does it have one). For example, if a pointer is given from an external source without a size, the resulting data container's size is undefined. The fact that some containers do not have a symbolic size should not disrupt the analysis of other symbols (iterates, transient containers, other data containers with size information).
Why is it a problem? Right now, if such a data container has no concrete size, or any other symbol remains in an SDFG, the generated code will include another argument with that symbol. This defers the error to a compilation error, or a segmentation fault if the SDFG is called with one fewer parameter. Such errors are unclear to a user, are reported too late, and are not attached to the right source information as to which part of the code caused it. For example, is it a result of an erroneous transformation? If it's not part of SDFG validation, one can never debug such an issue.
Implementation: symbolic.UndefinedSymbol will be a subclass of symbolic.symbol. Therefore, it will behave the same way as a normal symbol, with a few exceptions:
Undefined symbols have a name of "?" and any comparison with another symbolic expression will yield an indeterminate solution.
Like NaN values, any operation on an undefined symbol results in an undefined symbol after simplification. For example: N + ? = ?
During validation and code generation, if such a symbol is ever used in a way that would generate code, an informative exception will be raised.
Following the discussion on May 16, we would like to have a special kind of symbol, which is undefined.
Motivation: Symbolic analysis is crucial to DaCe and transformations. However, not every data container needs to have a concrete symbolic value for a program to function (nor does it have one). For example, if a pointer is given from an external source without a size, the resulting data container's size is undefined. The fact that some containers do not have a symbolic size should not disrupt the analysis of other symbols (iterates, transient containers, other data containers with size information).
Why is it a problem? Right now, if such a data container has no concrete size, or any other symbol remains in an SDFG, the generated code will include another argument with that symbol. This defers the error to a compilation error, or a segmentation fault if the SDFG is called with one fewer parameter. Such errors are unclear to a user, are reported too late, and are not attached to the right source information as to which part of the code caused it. For example, is it a result of an erroneous transformation? If it's not part of SDFG validation, one can never debug such an issue.
Implementation:
symbolic.UndefinedSymbolwill be a subclass ofsymbolic.symbol. Therefore, it will behave the same way as a normal symbol, with a few exceptions:N + ? = ?