[flang-commits] [PATCH] D149734: [flang][hlfir] Add hlfir.forall and its OrderAssignmentTreeOpInterface

[Jean Perier via Phabricator via flang-commits]

jeanPerier added inline comments.


================
Comment at: flang/include/flang/Optimizer/HLFIR/HLFIROps.td:1069
+
+    A Fortran forall with several indices is represented as a nest
+    of hlfir.forall.
----------------
vzakhari wrote:
> Sounds okay, but would we have more readable IR if we support multiple indices with a single `hlfir.forall`?  Having `hlfir.yield` return a vector of ints and having multiple blocks arguments in the body block does not sound too complex.  Will it make the lowering more complex?
Fair point, I thought a bit about having hlfir.yield returning multiple values (for the bounds remapping arguments of pointer assignments, that I have not yet covered). While it is possible and would not make lowering much more complex, it would make the data dependency a bit more complex: right now, I am planning to have a dumb approach that looks at all the operation in a region that yields a value, and if any of them has a read effect on a variable being assigned, to create a temporary for the value yielded.

If we move to yields with several values, the analysis will need to be more clever  to identify which yielded value is conflicting (it would need to follow the DAG an that is a more complex), or the pass will need to save all yielded values if there is any conflict in the region, just to be safe.

So I am rather inclined to have a heavier syntax until to have a conflict analysis as simple as possible to start with. Then, if we are confident we can have a "finer grain" analysis to detect which yielded entity conflicts, I would happy to move to a lighter syntax.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D149734