---
# System prepended metadata

title: 'Cartesian GTC: DaCe Backend'
tags: [cycle 2]

---

# Cartesian GTC: DaCe Backend

###### tags: `cycle 2`

shaped by: Linus

## Assigned

to Linus (full cycle) and Rico (second half of cycle) together with [Optimizations](https://hackmd.io/uUQyFT2NT_WnrkTUCaUlPA).

## Summary

The goal of this project is to add a library node expansion for the high level OIR-level SDFG to enable the use of the performance model tools of DaCe. Further, it is part of this project to add DaCe as a standalone backend to facilitate low-level experimentation of optimization schemes using the existing tools available in DaCe.

The project is largely independent of but related to the "Cartesian GTC: DaCe Optimizations" project. If it is not possible to allocate two developers to the projects, a single developer can implement parts a. of each project in the current cycle.

## Appetite

full cycle

possible developers:
- Linus, Felix, Anyone?

### Part a:

As a minimal first step towards the goal of the subproject, a naive library node expansion is implemented which does not support all the concepts currently represented in OIR. (e.g. no non-3d-fields, no caches) This is then used in a functional but feature-limited, non-optimized DaCe backend.

#### Task: Library Node Expansion
The goal here is to write a naive expansion of the library nodes, such that the result is an SDFG without any `LibraryNode`s. The graph represents the stencil computation validly, but performance is not to be considered. This can later be used to build a performance model and to provide DaCe researchers with a graph that can be optimized.


#### Task: DaCe backend
While the previous task is to create a SDFG that represents a valid computation that is ready to compile, this task would add the necessary API including python-side code generation to compile and use said graph as a backend from gtc.

### Part b:

Given the valid backend, it can be expanded into a backend generating code at the same level of feature support and optimization as the existing GTC backends.

As a first step, the features can be added to the OIR-level SDFG that was implemented in the last cycle (fields with !=3d, caches) to high level SDFG.

Depending on the outcome of the betting table, features and structural changes to OIR coming in the coming cycle could be an important part of this. 

Then, support for these features can also be added in the expansion such that the DaCe backend will be equivalent in performance and structure of the generated code to e.g. the GTC Cuda backend.

