[llvm-branch-commits] [mlir] [MLIR][OpenMP] Support clause-based representation of operations (PR #92519)

Sergio Afonso via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Fri May 17 04:35:03 PDT 2024


skatrak wrote:

> I like the idea, but also have some questions:
> 
>     1. How does an operation definition look like with all its clauses defined? Does it have to be repeated for each operation supporting the same clause(s)?

You can see how things would look like in #92523, but I can copy one example here:

```tablegen
def TeamsOp : OpenMP_Op<"teams", traits = [
    AttrSizedOperandSegments, RecursiveMemoryEffects
  ], clauses = [
    OpenMP_NumTeamsClause, OpenMP_IfClause, OpenMP_ThreadLimitClause,
    OpenMP_AllocateClause, OpenMP_ReductionClause
  ], singleRegion = true> {
  let summary = "teams construct";
  let description = [{
    The teams construct defines a region of code that triggers the creation of a
    league of teams. Once created, the number of teams remains constant for the
    duration of its code region.
  }] # clausesDescription;

  let builders = [
    OpBuilder<(ins CArg<"const TeamsClauseOps &">:$clauses)>
  ];

  let hasVerifier = 1;
}
```
> 
>     2. It seems this requires all properties of a clause specified in its constructor. Wouldn't it be better if you could subclass `OpenMP_Clause` and in there overwrite all the properties that are non-default?
> 

Actually this only requires the list of clauses themselves to be passed in to the definition of the `OpenMP_Op`. They are the ones that define all these properties, and they indeed all subclass `OpenMP_Clause` (see in #92521).

>     3. Have you considered to define/derive from all this info in OpenMP.td of LLVMFrontend? Clause information should be language-independent.

I get that, the issue is that the information being used here is very much MLIR dialect specific, and OMP.td in LLVMFrontend doesn't seem like the right place to be defining these things, since it's outside of the MLIR project. Maybe descriptions could potentially be moved there, but then we'd have some sort of matching system between clauses in LLVMFrontend and the ones in MLIR. Not sure how feasible that would be.

https://github.com/llvm/llvm-project/pull/92519


More information about the llvm-branch-commits mailing list