Various fixes to constants:
PsConstant
immutableinterpret_as
/reinterpret_as
to apply data types to constantsPsConstant
Frederik Hennig (83fc5764) at 28 Mar 15:41
extend typification tests to check type of each expression
This is an umbrella MR combining a few small changes:
Constant
inside of an untyped ConstantExpr
was encountered, the typification used to fail (see new test).test_typify_integer_binops
now that arbitrary expressions can be deferred.Frederik Hennig (d2cfa5a0) at 28 Mar 14:36
Merge branch 'bauerd/fix-const-typing' into 'backend-rework'
... and 1 more commit
I'm gonna look into it, but ideally that should never happen.
Anyway, allowing PsConstant.apply_type
to change the current constant object is probably a big pitfall, too, since PsConstant
DOES override __eq__
for content-equality.
Feel free to fix the root cause
Still, should it be allowed to give the typifier an untyped PsConstantExpr
wrapping a typed PsConstant
?
I do not see why not.
I admit that it is very non-obvious. The expression stems from one of our real applications which is how I found it.
It gets frozen to:
PsMul(PsSub(PsMul(Constant(-1: <untyped>), Symbol(PsSymbol(x, None))), Symbol(PsSymbol(y, None))), PsSub(PsMul(Constant(-1: <untyped>), Symbol(PsSymbol(x, None))), Symbol(PsSymbol(y, None))))
Now the typifier runs over this tree as follows (each line is the argument to visit_expr
):
PsMul(PsSub(PsMul(Constant(-1: <untyped>), Symbol(PsSymbol(x, None))), Symbol(PsSymbol(y, None))), PsSub(PsMul(Constant(-1: <untyped>), Symbol(PsSymbol(x, None))), Symbol(PsSymbol(y, None))))
PsSub(PsMul(Constant(-1: <untyped>), Symbol(PsSymbol(x, None))), Symbol(PsSymbol(y, None)))
PsMul(Constant(-1: <untyped>), Symbol(PsSymbol(x, None)))
Constant(-1: <untyped>)
Symbol(PsSymbol(x, None))
Symbol(PsSymbol(y, None))
PsSub(PsMul(Constant(-1.0: const float), Symbol(PsSymbol(x, float))), Symbol(PsSymbol(y, float)))
PsMul(Constant(-1.0: const float), Symbol(PsSymbol(x, float)))
Constant(-1.0: const float)
Notice how PsMul(Constant(-1: <untyped>), Symbol(PsSymbol(x, None)))
appears twice in the tree.
I suspect that both occurences reference the same PsConstant
Python object.
After typing the first expression, the dtype
of both PsConstant
s changes from <untyped>
to const float
.
However, the second PsCostantExpr
is not typed, yet.
This happens next and the typifier was not able to handle an untyped PsConstantExpr
containing a typed PsConstant
.
Thanks; this actually uncovers a more subtle bug in AST cloning: when cloning a PsConstantExpr
, its wrapper PsConstant
is not cloned along with it, so both copies refer to the same constant. Then one of them gets typified, which unintentionally carries over to the other. Gonna fix that right away.
This is an umbrella MR combining a few small changes:
Constant
inside of an untyped ConstantExpr
was encountered, the typification used to fail (see new test).test_typify_integer_binops
now that arbitrary expressions can be deferred.This MR implements equality and hashing for PsSymbol
such that the parameters of KernelFunction
s are unique.
Also improves some error messages.
Thanks for the explanation. Now I remember reading that in the documentation ^^
Content-based equality and hashing for PsSymbol
were not implemented intentionally to make sure that for every symbol, only one instance ever exists in the backend, and all symbol instances are known to and managed by the KernelCreationContext
.
This is necessary so that changes to a symbol in one place (e.g. setting or updating the data type) are immediately reflected across the AST. If we allow multiple instances of PsSymbol
to refer to the same object, the PsSymbol
cannot be mutable, and a lot of transformations become harder to implement.
The KernelCreationContext
acts as a symbol table; as long as you stick to using its interface (i.e. get_symbol
), you should never get symbol duplicates.
This MR implements equality and hashing for PsSymbol
such that the parameters of KernelFunction
s are unique.
Also improves some error messages.
We switch to python3.10
when conda
and the latest Ubuntu LTS version support that.
Apply pattern matching at important functions.
Frederik Hennig (e842ed85) at 27 Mar 18:16
Refactor and fix CI
The functions modulo_floor
, modulo_ceil
, div_floor
and div_ceil
of the integer_functions
exhibit unclear rounding behaviour. Their names and docstrings indicate mathematical rounding behaviour ("down" is negative infinity), while their implementation performs zero-oriented rounding ("down" is toward zero), as this is the default behaviour of C /
and %
.
We should clarify the semantics of these functions and adapt docstring, implementation, or both.
See also the discussion here: !368
Frederik Hennig (f0de552f) at 27 Mar 17:17
Add support for function materialization.
Frederik Hennig (0e4677de) at 27 Mar 17:03
Refactor Type Handling and Typification