---
# System prepended metadata

title: '[GT4Py] GTIR pipelines'
tags: [cycle 25 - 10/24]

---

# [GT4Py] GTIR pipelines

<!-- Add the tag for the current cycle number in the top bar -->

- Shaped by:
- Appetite (FTEs, weeks):
- Developers: <!-- Filled in at the betting table unless someone is specifically required here -->

## Problem

Goal is to bring a GTIR-embedded and a GTIR-DaCe pipeline into GT4Py main which is tested with the integration_tests and validating with the active ICON4Py stencil tests.

We exclude patterns including the `scan` and `as_offset` builtins.

## Appetite

full cycle

## Solution

### Transformations

#### Transformation pipelines

Compose 2 sets of transformation pipelines
- One for a fieldview-like representations (the one that is used in DaCe-fieldview and gtir-embedded)
- One that produces localview-like representation (the current `apply_common_transforms`) to be used with gtfn or and itir_embedded.

#### Decouple domain and type inference

The goal is to be able to do collapse tuple before domain inference. Type inference will get rid of its dependency on domain inference by applying `trace_shifts` for deducing dimensions, instead of relying on domain inference for this information. The latter cannot currently provide this information for fields that are not used, e.g. a partially used tuple.

#### Minor

- Clean implementation of https://github.com/edopao/gt4py/pull/5/commits/7e3bdfc7ff6f85a5305468a96673e40d85683d3b

### GT4Py embedded

Deal with Fields that conceptually contain `_List`s. At ITIR level neighbors are represented with a `_List` type. In the upgrade to GTIR, the `as_fieldop`ed `neighbors` builtin will return a Field. Currently, by implicit conversion this is a Field of `tuple`s, which is not valid in neighbor-expression.

### DaCe lowering

#### Implement support for the neighbor `map` and `make_const_list` builtins

##### Summary
- full-connectivity case: in place, no problems
- skip-values:
    1. handle skip-values while lowering
    2. handle skip-values (but also neighbors-map-reduce in general) by means of domain-specific library nodes

##### Details
The lowering of map-reduce for the full-connectivity case is straightforward. It was already implemented during cycle 24 cooldown, although it is not reviewed yet.

For the skip-values case, there are different approaches. The proposed approach to start with is to annotate the offset provider (aka connectivity table) on the dace storage of temporary arrays containing skip values. In this way, lowering of `map` will check if the input arrays have such attribute and apply an additional check for skip values. This approach is easy to implement and will provide some level of optimization, but it comes with drawbacks: 1. the optimization is done during the lowering to SDFG and 2. the resulting SDFG does not have the semantics of masked array nor of field neighbors. Point 1 means that we are mixing lowering and optimization logic (not good, optimization should happen after lowering). Point 2 implies that we cannot further apply domain-specific optimizations to the SDFG.

In order to deal with these drawbacks, we would probably need to introduce domain-specific library nodes for `neighbors`, `map` and `reduce` to transfer the GT4Py semantics to the SDFG. This would enable to develop domain-specific transformations, that would translate masked arrays to non-masked arrays with proper identity value (the same result of the mixed lowering-optimization approach proposed as first step). Another transformation, ideally, would allow to produce composition of neighbor tables.

Question 1: Should we prioritize the design of domain-specific library nodes or the performance evaluation of current lowering?

Question 2: Introducing domain-specific library nodes will imply that we have to write new dace transformations so that they are expanded and lowered to standard SDFG, before we can reuse DaCe transformations. Are the plans to implement similar transformations in GT4Py?

## Rabbit holes


## No-gos

`Scan` and `as_offset` (because of domain inference problems, see https://github.com/GridTools/gt4py/issues/1676) are out of scope.

## Progress
<!-- Don't fill during shaping. This area is for collecting TODOs during building. As first task during building add a preliminary list of coarse-grained tasks for the project and refine them with finer-grained items when it makes sense as you work on them. -->

- [x] DaCe lowering
    - [x] Map/reduce with full connectivity and with skip values
    - [x] Broadcast
    - [x] Let-statements
    - [x] Zero-dimensional fields
    - [x] Replace unicode symbols created by SSA IR pass ([PR1696](https://github.com/GridTools/gt4py/pull/1696))
    - [x] Setup GTIR dace backends ([PR1705](https://github.com/GridTools/gt4py/pull/1705))
    - [ ] [refact] Build on the solution chosen for GTIR Embedded (`offset_type`, see [PR1703](https://github.com/GridTools/gt4py/pull/1703)) to return information about the local dimension.
    - [ ] Lowering of field operators with non-zero-aligned domain.
        - In other words, allocate array for field domain range between lower and upper bound (requires alternative solution for array offset)
    - [ ] Lowering of `as_offset`
    - [ ] Lowering of `concat_where` (GTIR not ready)
    - [ ] Lowering of `index`
    - [ ] Lowering of `scan`
- [ ] Task 2
    - [x] Subtask H
    - [ ] Subtask J
- [ ] Discovered Task 3
    - [ ] Subtask L
    - [ ] Subtask S
- [ ] Task 4

__Discussion: Decouple domain and type inference__

Maybe allow no domain