Input, Output, InputOutput Fields

[mroethlin]

General Observations

In dawn, there is no distinction between the intent of a field, i.e. if the field is input, output or input/ouput field (in, out, and inout for shot) with respect to a series of statements, and the access mode of a field, i.e. if it was written to, read from, or both.

Consider e.g.

a = 1
a = a + 1

So here, the field a would be inout, even though it's clearly and out field, simply because it is both written to and read from. Maybe worse, dawn queries the intent of a field to determine whether it is written to, read from, or both. So dawn does no semantic distinction of intent and access mode of a field.

This is a problem with regards to our verification framework for ICON since we want to avoid classifying fields as inout when they are, in fact out (since inout fields require maintaining a manual copy on the FORTRAN driver side).

Intent detection algorithms

The problem whether a field is in, out or inout is undecidable in general due to run time conditionals:

b = a
if c:
  a = 1

However, we can still argue whether a field is inout potentially. There are two algorithms proposed to do that.

Algorithm 1, @Stagno

Simply "classify as inout if a read exists which is not preceded by a write to the same field"

• easy to implement
• may misclass some fields in some situations, see below

Algorithm 2, @cosunae

Before we dive into the algorithm, let's first consider a few examples where algorithm 1 breaks.

The first problem I see with the algorithm (above) is the loop order. It iterates over the IIR stmts without taking into account the vertical loop order

for 2,kend
  x = a[k-1]
  a = 

In this case the algorithm would mark it IO while in reality is Output only
However in this case

for 1,kend-1
  x = a[k+1]
  a = 

It is indeed an IO
Second problem I see is the order of iteration over stmt does not need to follow the order of iteration of execution in our parallel model, considering intervals

for 1,kend
  do ( interval=[kend-1,kend])
      a = 
  do (interval = [1, x?] )
      ... = a[k+1]

The algorithm will say it is output only, however in reality it will depend on x? if x == kend-2, then it is output only, otherwise it is IO. Therefore the algorithm is not only more conservative than it should, but it is also not right in some cases, since there can be IO cases not caught.

Now, a proposal for an algorithm that would solve that. This is Algorithm 2 by Carlos.

given a non empty interval where there are reads executed before writes (name it irbw) the field is either input or input/output. Any write access within any interval will make the field I/O, otherwise it will be input only.
Summarizing, if irbw is not empty and there is at least a write, the field is I/O. If irbw is not empty and there are no writes the field is input only. If irbw is empty, the field is output only.
From some of the examples above:
ex1:

for 2,kend
  x = a[k-1]
  a = ...

irbw = [1,1]; iw= [2,kend] therefore a is I/O
ex2:

for 1,1
  a=0
for 2,kend
  x = a[k-1]
  a = ...

irbw = null; iw= [1,kend]; therefre a is output only

ex3:

for kend,2
  x = a[k-1]
  a = ...

irbw=[1,kend-1]; iw = [2,kend], therefore a is I/O

ex4:

for 1,1
  a=0
for 3,kend
  x = a[k-1]
  a = ...

irbw = [2,2]; iw= [1,1] U [3,kend]; therefre a is I/O (bearbeitet)

Dawn - Architectural Considerations

• There are passes that rely on the (wrong) assumption that a field is an inout field as soon as it was written to and read from, e.g. PassSetCaches
• Dawn holds intent information for each field on any of the Stencil, Multistage, Stage and DoMethod IIR Nodes. Currently, the information is simply duplicated to what was computed on the DoMethod. The DoMethod assigns in, out and inout intents according to the read, write, read&write criterion.
• Conceptually, the intent of each field may be different on any of the IIR nodes. For example a field can be an output field of a stage, but from the perspective of the multistage said stage is contained in, it can be an inout field.

Conclusions

There are different levels on which this issue can be approached, with wildly varying degrees of effort and payoff:

• [Easy] leave everything as is, inject algorithm 1 or 2 into code generation
• [Medium] Inject algorithm 1, or preferable 2, into each Stencil, MultiStage, Stage IIR element to reflect the fact that each field may have different roles with regards to each of those IIR elements
• [Nightmare] Re-work the intent completely such that semantics of intent and access mode are properly reflected in dawn