feature[next]: Non-tree-size-increasing collapse tuple on ifs

[tehrengruber]

Removing the tuple expressions across if_ calls on ITIR has been a pain point in the past. While the PROPAGATE_TO_IF_ON_TUPLES option of the CollapseTuplePass works very reliably, the resulting increase in the tree size has been prohibitive. With the refactoring to GTIR this problem became much less pronounced, as we could restrict the propagation to field-level, i.e., outside of stencils, but the tree still grew exponentially in the number of references to boolean arguments used inside if_ conditions. This PR adds an additional option PROPAGATE_TO_IF_ON_TUPLES_CPS to the CollapseTuplePass, which is similar to the existing PROPAGATE_TO_IF_ON_TUPLES, but propagates in the opposite direction, i.e. into the tree. This allows removal of tuple expressions across if_ calls without increasing the size of the tree. This is particularly important for if statements in the frontend, where outwards propagation can have devastating effects on the tree size, without any gained optimization potential. For example

complex_lambda(if cond1
  if cond2
    {...}
  else:
    {...}
else
  {...})

is problematic, since PROPAGATE_TO_IF_ON_TUPLES would propagate, and hence duplicate, complex_lambda three times, while we only want to get rid of the tuple expressions inside of the if_s. Note that this transformation is not mutually exclusive to PROPAGATE_TO_IF_ON_TUPLES.

[havogt]

Need more documentation of the new trafo or additionally a more detailed explanation on how it works.

[havogt]

Why is this assert useful?

[tehrengruber]

In case one (erronously) returns the same node again instead of None to signify no change, fp_transform runs into an endless loop. This is a cheap way to prevent this case.

[havogt]

Here we iterate over any functions args or do we know more?

[tehrengruber]

No we don't know more. We need to build and simplify the continuation first to know if we want to transform. It might be possible to handle multiple ifs, but the code would become more complex and error prone, and there is no benefit. It is just important to remember that the entire node is split into the continuation and the first matching if argument.

[havogt]

Where is the statefulness?

[tehrengruber]

Reformulated:

Note that this function alters the input node, which is usually desired, and more performant.

[havogt]

I only have a few proposals to improve readability.