Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for non literal accesses in the K dimension #980

Closed
5 tasks
twicki opened this issue May 27, 2020 · 0 comments · Fixed by #1023
Closed
5 tasks

Support for non literal accesses in the K dimension #980

twicki opened this issue May 27, 2020 · 0 comments · Fixed by #1023

Comments

@twicki
Copy link
Contributor

twicki commented May 27, 2020

  • Design
  • How to deal with out of bounds issue
  • Implementation
  • Safety Checks
  • Connection to GT4Py
mroethlin added a commit that referenced this issue Sep 23, 2020
## Technical Description

This PR introduces vertical indirections. In Pseudocode:
```
for all levels k:
  for all cells c:
    out[c,k] = in[c,vert_nbh[k]]
    out[c,k] = in[c,vert_nbh[k]+1] //additional shift
```
More complicated constructs are disallowed, e.g. `out[c,k] = in[c,vert_nbh[k+1]]`, `out[c,k] = in[c,vert_nbh[vert_nbh_inner[k]]]` and `out[c,k] = in[c,vert_nbh1[k+1]+vert_nbh2[k+1]]` would all be illegal.

### Design

A `VerticalOffset` class was introduced. What was formerly known as `verticalOffset` (i.e. the integer to shift k) was renamed to `verticalShift` and encapsulated into that `VerticalOffset` class, along with a `FieldAccessExpr` known as `verticalIndirection`. The interface prohibits direct construction of the `verticalIndirection`, the underlying constructor is wrapped by the `VerticalOffset` s.t. only `FieldAccessExpr`s without Offsets can be constructed. 

Unfortunately, some limitations of the Visitor infrastructure drove some design decisions, e.g.
* the `verticalIndirection` is actually stored as `std::shared_ptr<Expr>` because `getChildren()` returns `ArrayRef<std::shared_ptr<Expr>>`, i.e. access to the original `shared_ptr` is required due to the `ArrayRef`
* getting a _mutable_ reference `std::shared_ptr<Expr>& getIndirectionFieldAsExpr();` is required since there is no proper `const` visitor. 
These observations highlight the importance of [this issue](#617)

The presence of the vertical Indirection has deep consequences with regards to the `Extents` and `Intervals`, since they can both be constructed or modified with the `Offsets`. The presence of a vertical indirections implies that an **extent or an interval can become undefined**. This undefined state is either propagated, e.g. merging an offset with a an undefined offset makes the offset undefined, or simply leads to assertions, e.g. computing the gap intervals of a vector of intervals with some intervals being undefined is illegal. It was carefully evaluated with operation should propagate and which operations should be prohibited, in parts by the requirements imposed by the passes. However, there may still be edge cases we didn't catch. 

## Testing

* The usual slew of de/serialization tests for the new `Offsets` as well as the undefined value of the `Extent` (not required for `Interval` since only `SIR::Interval` is serialized, which does not carry an undefined state)
* Tests ensuring the propagation / prohibiting of `Extent` / `Interval` ops in undefined state.
* `Dawn4Py` tests exercising the newly introduced vertical indirections, also in presence of field versioning etc.
* In a preliminary step, a utility called `testMutator` was introduced to mutate IIR in such a way that each read becomes indirected. This was used to get a good idea about the affected parts of the code, but is currently unused. It remains in the PR in the hopes it may be useful for possible future debugging.

Unfortunately, `dusk` is not ready for vertical indirections yet. It is expected that going end to end might uncover some currently missed edge cases

## Dependencies

This PR is independent, but relies on a [previous refactoring](#1022) to work. 

## Resolves / Enhances

Fixes #979
Fixes #980
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant