This PR fixes the double-free bug mentioned in #911, but is still in draft state, because I suspect it can create memory leaks in certain cases. No review required at the moment.
The MLIR operation arith.select is frequently created during the canonicalization of scf.if (which, in turn, is created by DaphneDSL if-statements).
arith.select takes a boolean argument (condition) plus two additional arguments, one of which it selects/returns based on the value of the condition.
arith.select needs to be taken into account in DAPHNE's object reference counter management, because:
We decrease the reference counter of SSA values after their last use as operands (the arith.select could be the last user).
We have no clue which of the two last operands of arith.select is returned at run-time.
However, the return value is the same runtime object as one of the two latter operands.
To ensure the correct reference counter for the result after the arith.select, we need to increase the counter of the result before we decrease the counters of the operands.
We had already implemented this fix, but applied it only for string operands/results.
However, we must apply the fix for all operand/result types that have a reference counter at run-time.
Fixed ManageObjRefPass.
Added several script-level test cases testing the behavior for matrices, frames, lists, and strings and different settings of the if-then-else in DaphneDSL.
This PR fixes the double-free bug mentioned in #911, but is still in draft state, because I suspect it can create memory leaks in certain cases. No review required at the moment.