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

Update field access name #1022

Merged
merged 1 commit into from
Sep 10, 2020

Conversation

Stagno
Copy link
Contributor

@Stagno Stagno commented Sep 10, 2020

Technical Description

Update FieldAccessExpr::getName() to be the correct name (found in metadata).
Adds equality check in IntegrityChecker.

Resolves / Enhances

resolves #591

@Stagno
Copy link
Contributor Author

Stagno commented Sep 10, 2020

launch jenkins

Copy link
Contributor

@mroethlin mroethlin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

excellent, thanks

@Stagno Stagno merged commit 5f5645b into MeteoSwiss-APN:master Sep 10, 2020
@mroethlin mroethlin mentioned this pull request Sep 23, 2020
mroethlin added a commit that referenced this pull request 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
@Stagno Stagno deleted the update_field_access_name branch October 26, 2020 10:59
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 this pull request may close these issues.

Issue with Access IDs on FieldAccesExpr
2 participants