[all-commits] [llvm/llvm-project] 70bd2b: [mlir][openacc] Refine data operation data clause ...

[Razvan Lupusoru via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 70bd2b8b354b2239f0cc80c99f819c4df8ece9c7
      https://github.com/llvm/llvm-project/commit/70bd2b8b354b2239f0cc80c99f819c4df8ece9c7
  Author: Razvan Lupusoru <rlupusoru at nvidia.com>
  Date:   2023-04-19 (Wed, 19 Apr 2023)

  Changed paths:
    M mlir/include/mlir/Dialect/OpenACC/OpenACCOps.td
    M mlir/lib/Dialect/OpenACC/IR/OpenACC.cpp
    M mlir/test/Dialect/OpenACC/ops.mlir

  Log Message:
  -----------
  [mlir][openacc] Refine data operation data clause attribute

The data operations added in D148389 hold two data clause fields:
"dataClause" and "decomposedFrom". However, in most cases, dataClause
field holds a default value (except for acc_copyin_readonly,
acc_create_zero, and acc_copyout_zero).

The decomposedFrom field holds the original clause specified by user.
As work began on lowering to these new operations [1], it seems that
having both fields adds a bit of ambiguity. There is only one scenario
where we actually intended to use both:
acc data copyout(zero:)

The original intent was that this clause would be decomposed to
the following operations:
acc.create {dataClause = acc_create_zero, decomposedFrom =
acc_copyout_zero}
...
acc.copyout {dataClause = acc_copyout_zero}

However, we can encode the zero semantics like so without need of both:
acc.create {dataClause = acc_copyout_zero}
...
acc.copyout {dataClause = acc_copyout_zero}

Thus get rid of the decomposedFrom field and update verifier checks
to check for all data clauses that can be decomposed to the particular
operation.

So now the dataClause holds the original user's clause which simplifies
understanding of the operation.

[1] https://reviews.llvm.org/D148721

Reviewed By: clementval

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