[all-commits] [llvm/llvm-project] 4f30a6: [flang][hlfir] Implement the scheduling part of hl...

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4f30a63ca2a6cbc16beaa49df16373d020118e92
      https://github.com/llvm/llvm-project/commit/4f30a63ca2a6cbc16beaa49df16373d020118e92
  Author: Jean Perier <jperier at nvidia.com>
  Date:   2023-05-17 (Wed, 17 May 2023)

  Changed paths:
    M flang/include/flang/Optimizer/Dialect/FIROps.td
    M flang/include/flang/Optimizer/HLFIR/HLFIROps.td
    M flang/include/flang/Optimizer/HLFIR/Passes.td
    M flang/lib/Optimizer/HLFIR/Transforms/CMakeLists.txt
    M flang/lib/Optimizer/HLFIR/Transforms/LowerHLFIROrderedAssignments.cpp
    A flang/lib/Optimizer/HLFIR/Transforms/ScheduleOrderedAssignments.cpp
    A flang/lib/Optimizer/HLFIR/Transforms/ScheduleOrderedAssignments.h
    A flang/test/HLFIR/order_assignments/forall-fusing-scheduling.f90
    A flang/test/HLFIR/order_assignments/forall-scheduling.f90
    M flang/tools/bbc/bbc.cpp

  Log Message:
  -----------
  [flang][hlfir] Implement the scheduling part of hlfir.forall codegen

The lowering of hlfir.forall to loops (and later hlfir.where) requires
doing a data dependency analysis to avoid creating temporary storage for
every control/mask/rhs/lhs expressions.

The added code implements a data dependency analysis for the hlfir
ordered assignment trees (it is not specific to Forall since these nodes
includes Where, user defined assignments, and assignment to vector
subscripted entities, but the added code is only plugged and tested
with hlfir.forall in this patch).

This data dependency analysis returns a "schedule", which is a list of
runs containing actions. Each runs will result in a single loop nest
evaluating all its action "at the same time" inside the loop body.
Actions may either evaluating an assignment, or saving some expression
evaluation (the value yielded inside the ordered assignment hlfir operations)
in a temporary storage before doing the assignment that requires this
expression value but may "conflict" with it.

A "conflict" is a read in an expression E to a variable that is, or may
be (analysis is conservative), written by an assignment that depends on
E.

The analysis is based on MLIR SideEffectInterface and fir AliasAnalysis
which makes it generic.

For now, the codegen that will apply the schedule and rewrite the
hlfir.forall into a set of loops is not implemented, but the scheduling
is tested on its own (from Fortran, because it allows testing many cases
in very readable fashions).

The current scheduling has limitations, for instance
"forall(i=1, 10) x(i)=2*x(i)" does not require saving the RHS values for
all "i" before doing the assignments since the RHS does not depend
on values computed during previous iterations. Any user call will also
trigger a conservative assumption that there is a conflict. Finally,
a lot of operations are missing memory effect interfaces (especially
in HLFIR). This patch adds a few so that it can be tested, but more
will be added in later patches.

Differential Revision: https://reviews.llvm.org/D150455