[PATCH] D112445: [fir] Add fir.array_access op

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

Thanks for the example, that's very helpful!

Just trying to lay down how I understand this, it seems like there should be a reasonable abstract model allowing to reason about each of these ops/types in isolation:

1. ` !fir.array` is a value type, so it is immutable. It is a multi-dimensional array of value, but also keeps track of which values are "updated", where "updated" just means that it comes from the right-hand side of an `array_amend` or updated with a `fir.store`.
2. `fir.array_load` loads a  !fir.array` from memory, no value is marked as "updated".
3. `fir.array_access` provides a reference to a single element from an array. This is *not* a view in the immutable array, otherwise it couldn't be stored to. It can be thought of as a copy of the array element + the coordinate in the array. On its own this reference can be written to and modified without changing the array it comes from. Something unclear with this abstract model would be the lifetime of this new "object": but we could consider that this has the effect of an "alloca" and dies with the current scope.
4. `fir.store` on a reference obtained by `fir.array_access` is storing a new value to this reference, nothing special here.
5. `fir.amend` updates an array with a reference: the reference contains a value and the location where to update the value. The location in the resulting array is marked as "updated".
6. `fir.array_merge_store` updates the value on its LHS with the "updated value" from its RHS and store the result.

Is this consistent with the semantics model you have? (I don't have a complete picture of your implementation downstream, so it'd be useful to describe this and write it down, happy to help with this if needed)

(An alternative model to this "array_access" that produces a writeable location could be to produce a new array instead, taking inspiration of a similar value type array: the `builtin.tensor` type (see https://mlir.llvm.org/docs/Dialects/TensorOps/#tensorinsert-mlirtensorinsertop ). But that has other issues.)

(as a side-note, there is something a bit hard to grasp in your example in terms of SSA semantics when combining a parallel loop with an `iterarg`, but that's also an active topic of discussion in MLIR in general: we just looked at it recently again in the context of parallel tiling on tensors <https://llvm.discourse.group/t/open-mlir-meeting-10-28-2021-discussion-about-tiling-on-tensors/4604>)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112445/new/

https://reviews.llvm.org/D112445