fix[next-dace]: Map stride of local dimension in nested SDFG

[edopao]

This PR contains 3 kinds of changes:

1. A bugfix in mapping the stride of local dimension into the nested SDFG of if expressions.

inner_desc = dace.data.Array(
    dtype=arg_desc.dtype,
    shape=(arg_desc.shape[local_dim_pos],),
    strides=(arg_desc.strides[local_dim_pos],),
)

2. Addition of connectivities. This is needed to support the pattern with can_deref expressions (not part of this PR, see feat[next-dace]: Lowering mixed-GTIR to SDFG #2467). After GTIR transformations, which unroll the neighbors loops, a common pattern in grids with skip values is if(can_deref(a, V2E), deref(a(V2E)) + 2, 0).

3. Renaming of function parameters.

Blueline performance is in pair with baseline.

[philip-paul-mueller]

I am not fully happy with this change because it has potentially big implication for the IfMover and the condition fuser (which will stop working, since it can no longer identifying which If-Blocks can be moved together.
Because of these implication we must absolutely make sure to also run MuPhys, because, it will be very much impacted by these changes.

I am actually not sure if the data locality is actually improved, because in the almost everything has a restrict keyword, so the compiler should be smart enough tio figuring that out.
But this is just my concern or have you different opinions @iomaganaris

[edopao]

I am not fully happy with this change because it has potentially big implication for the IfMover and the condition fuser (which will stop working, since it can no longer identifying which If-Blocks can be moved together. Because of these implication we must absolutely make sure to also run MuPhys, because, it will be very much impacted by these changes.

I am actually not sure if the data locality is actually improved, because in the almost everything has a restrict keyword, so the compiler should be smart enough tio figuring that out. But this is just my concern or have you different opinions @iomaganaris

I see your point, makes sense. This change is not part of the bugfix, so I could revert it.

[edopao]

I have applied the review comments from @philip-paul-mueller, I agree totally. I have reverted the modification to the lowering of the condition: this change introduced a performance regression. Below the blueline performance plot:

• gt4py_timers_fix_stride: the current state of the PR, after reverting the modification to the lowering of the condition.
• gt4py_timers_fix_stride_and_move_cond: the previous state of the PR, which moved the evaluation of the if-condition inside the nested SDFG.

[philip-paul-mueller]

LGTM, although I have two smallish points.

[philip-paul-mueller]

Question: If this function is called in a uniform way I would expect that the data descriptor is either already added to the sdfg or not in all cases. So this if locks a bit fishy to me but maybe I miss something.

[edopao]

The origin of this if is that I am adding globals as I encounter them while visiting the if branches. I am visiting one branch at a time, so it could be that some globals have already been added in the previous branch.