# Research: Improve ICON Liskov

###### tags: `cycle 15`

Developers: -

Support: -

Appetite: full cycle

Shaped by: Christoph (mostly based on document from last cycle [here](https://hackmd.io/D2uarKUlS8-sN5TUKYXWEg))

## Background

In the last cycles, Liskov reached a fair level of maturity, but some features are still missing. This project is an effort to finish its development.

## Goals

- [x] Support for fused stencils: Fused stencils will become a necessity soon, since they are indispensible for efficient execution of the gt4py stencils. Icon Liskov should support them in the sense that the right pieces of OpenACC code should be removed in the precense of merged stencils
- [ ] We currently use a `wrap_run_and_verify` function wrapper that either runs, or runs _and_ verifies a stencil. This is because we can only distinguish a subsitution run from a verification run based on the presence of a pre-processor `#define`. However, using Liskov, we could generate the correct callin the first place
- [ ] **or** investigate the impliations of having a _run time_ verification/substitution flag
* Pro: This saves a compile step, ...
* Con: Pointers need to be declared in either mode, but allocated in verification mode only (more clutter), ...
- [x] incorporate data regions of before fields into stencils

## Non-Goals

* Do not try to make Liskov fuse stencils on its own

## Known Tasks

### Fused stencil support

Two possible designs.
* Define `start fused stencil` and `stop fused stencil` markers, which generate the call to the fused stencil and delete everything inbetween start and end for substitution mode.

Problem: Danger of unbalancing `if-else` structures and `#defines`.

Solution: Use the `!$DSL INSERT` directive to insert the necessary lines to make the code correct again.

Con: Increases complexity of directive code in ICON Liskov through potential usage of multiple `INSERT` statements.

Pro: Relatively small extension to Liskov.

* Define `start fused stencil` and `stop fused stencil` markers, which generate the call to the fused stencil as well as the before field copies for the fused stencil. Only delete the code pieces inbetween already existing single stencil markers. Can be implemented by changing the behaviour of the`IntegrationGenerator` to ensure that all code between `StartStencil` and `EndStencil` directives that are within the context (line numbers) of a fusion marker, are disabled, for example by instead of generating stencil integration code for the affected stencils, an `#ifdef <MACRO>` will be generated instead. The macro should always be false (by omitting it from the icon build system) thus those code blocks will never execute.

Pro: Has the benefit of only disabling code that needs to be disabled.

Con: Makes the design of Liskov a little more complex.

### Generating different code for verification and substititon .OR. making the branching runtime

* Research pros and cons until decide for one design
* generate different code: use `run_stencil` and `verify_stencil` instead of the `wrap_run_and_verify` method`
* runtime branching: Change the `__DSL_VERIFY` macro into a (global?) runtime boolean

## Code examples

DSL: fused_stencil_01_02_03_start
fused_scope=true

DSL: stencil_01 start
DSL: stencil_01 end
DSL: stencil_02 start
DSL: stencil_02 end
DSL: stencil_03 start
DSL: stencil_03 end

CALL green_gauss ! fused_scope == true deactivates green_gauss

DSL: fused_stencil_01_02_03_end
fused_scope=false

CALL green_gauss

Problem with if-deffing out all single stencils and then calling the fused one:

green_gauss    ! subroutine in another module
btraj_o1       ! subroutine in another module
stencil_15

Solution:
liskov generates in the file where SUBROUTINE `btraj_o1` is defined

green_gauss.f90

IF .fused_scope. !global varialbe defined in p_patch
THEN
    ! skip stencil
ELSE
    execute stencil