# Frontend Feature Support for DaCe Backend ###### tags: `cycle 14` - Developers: Linus, Peter - Appetite: two developers, half a cycle (3 weeks) ## Problem <!-- The raw idea, a use case, or something we’ve seen that motivates us to work on this --> The [DaCe research project of the previous cycle](https://hackmd.io/G1Guwgv-ShawKe5Aii3tzQ) evaluated different options for implementing a DaCe backend to declarative GT4Py. Finally an approach was chosen and pursued where SDFGs are generated based on ITIR with indirect memory access being implemented by having separate tasklets performing the lookup. However, the work did not yet lead to a feature complete backend. (Which was also not intended.) The current limitations and shortcomings are documented [here](https://github.com/petiaccja/gt4py/blob/dace-backend-experimental/docs/development/ADRs/0014-DaCe_backend.md). The **deficiencies** targeted in this cycle are the following, **in order of priority**: - [ ] **Review & cleanup**: the coding patterns, especially those accessing the DaCe API may be simplified substantially (Linus) - Reason: before we start adding more things, we should clean up. Linus knows the DaCe API better. - [x] **Tuples**: iterators of tuples are not supported (Peter) - Reason: a large number of frontend tests use tuples - [x] **Types** of expressions are hardcoded as float64 and int64. (Either) - Reason: proper typing is simply a must for any useful backend - [x] **Typecasting** of expressions is not supported by the SDFG generation (Linus, small task) - Reason: low hanging fruit, I just have no clue how to typecast in DaCe but Lex should be able to help - [ ] **Scans** are not supported (Linus) - Reason: scans are important and are part of several tests, but not the highest priority because you have a complete (though less capable) system even without scans - [x] **Lambda** expression within stencils (that are called in stencil closures) are not supported (Peter) - Reason: needed for ITIR passes like common subexpression elimination. Strictly speaking we can live without this feature, but it may result in performance degradation and code bloat In the unlikely event that we are done with all these, the remaining documented features can also be addressed. ## Goal <!-- How much time we want to spend and how that constrains the solution --> The previous project was good enough as a prototype, but not good enough to actually be merged. The goal for this cycle is to cover the majority of frontend use cases by supporting additional ITIR features and to consolidate the code. After the 3 weeks allocated for this project, we should have a usable DaCe backend that can be merged into the main branch. ## Solution <!-- The core elements we came up with, presented in a form that’s easy for people to immediately understand --> - **Review & cleanup**: my idea is that Linus could look over the DaCe code I wrote and he may be able to suggest some simplifications of the API use given his expertise. I don't know Linus' idea. - **Tuples** can be resolved by "flattening" iterator to tuples by using different fields to represent every entry of the tuples, effectively translating iterators of `n`-tuples to a collection of `n` fields - **Type** deduction is now available in GT4Py, so the current backend can be amended to use this information. - **Scans** can be implemented with what is the standard practice to represent loops in dace: Based on state machines (usually in nested SDFGs) with backward edges. - **Typecasting** should be fairly straightforward, I just don't know the syntax to use in DaCe Python tasklets - **Lambdas** can be supported by adding yet another SDFG nest within the stencil's nested SDFG ## Rabbit holes <!-- Details about the solution worth calling out to avoid problems --> ## No-gos <!-- Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the ## appetite or make the problem tractable --> Performance of the backend is not a concern. The use of the indirection library node of the other project of this cycle is not a goal. (But here, an approach where indirection is done with a lookup tasklet, shall be implemented, so that a later switch is simple.) A complete support of iterator IR is not the goal, nor is a distinct graph for each iterator IR stencil. (I.e. non-semantic changes to the IR do not necessarily reflect in the SDFGs structure.) The above linked document listing current limitations of the backend mentions "Library nodes for indirect indexing" as a Non-feature improvement. This is not the scope of this project but is rather [shaped separately](https://hackmd.io/FlTtdLvmSES1qY3VWiE_Vg) In general, the points of said sections are not goals of this project.