This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][OpenMP] Fixed the missing inclusive clause in omp.wsloop and fix order clause
ClosedPublic

Authored by shraiysh on Oct 20 2021, 9:15 PM.

Details

Summary

This patch adds the inclusive clause (which was missed in previous
reorganization - https://reviews.llvm.org/D110903) in omp.wsloop operation.
Added a test for validating it.

Also fixes the order clause, which was not accepting any values. It now accepts
"concurrent" as a value, as specified in the standard.

Diff Detail

Event Timeline

shraiysh created this revision.Oct 20 2021, 9:15 PM
shraiysh requested review of this revision.Oct 20 2021, 9:15 PM

@peixin @kiranchandramohan does this look okay? Please review it as this handles failing test cases in CI.

shraiysh updated this revision to Diff 381146.Oct 20 2021, 10:09 PM

Rebase with main as the commit with failing tests was reverted.

clementval added inline comments.Oct 21 2021, 12:10 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
917

That would be nice to be able to generate this kind of list from the OMP.td file so this kind of problem would not occur.

clementval accepted this revision.Oct 21 2021, 12:11 AM
This revision is now accepted and ready to land.Oct 21 2021, 12:11 AM

I will land this patch now.

mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
917

Hmm, that is true. I will try to look into this sometime later.

Please double check any other clauses are not missed in test cases.

It seems that order clause test is also missed in ops.mlir. It would be better to add the test cases for each clause wsloop and parallel directive since your previous PR made changes to this part.

clementval added inline comments.Oct 21 2021, 12:29 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
917

Sure it's not smth urgent right now but good to keep it on the omp todo list.

kiranchandramohan requested changes to this revision.Oct 21 2021, 1:27 AM
kiranchandramohan added inline comments.
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
917

inclusive is not a clause from the OpenMP standard. It is a property of the DO loop associated with the OpenMP worksharing loop. Just like we do not have upper_bound, lower_bound and step as clauses here, I think we should not list inclusive also as a clause and deal with it like upper_bound, lower_bound and step.

BTW, the test for inclusive was in generic syntax that is why we did not catch missing this. As @peixin says it will be good to go through all the clauses and see whether there is a test for the pretty syntax.

This revision now requires changes to proceed.Oct 21 2021, 1:27 AM
shraiysh updated this revision to Diff 381196.Oct 21 2021, 3:34 AM

Thanks @kiranchandramohan @peixin and @clementval for the review.

Moved inclusive out of clauses. Added tests for other clauses. Please let me know if you see any missing test-cases. I have not added failing test cases for the clauses which are allowed by the standard but not supported by the operations right now.
Handled order clause, the constraint was not accepting the concurrent value and the default value could not be provided by the user. So, essentially it was absent. Added test for the same.

Herald added a project: Restricted Project. · View Herald TranscriptOct 21 2021, 3:34 AM
shraiysh marked 3 inline comments as done.Oct 21 2021, 3:35 AM
shraiysh added inline comments.
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
917

Done!

shraiysh updated this revision to Diff 381237.Oct 21 2021, 6:13 AM
shraiysh marked an inline comment as done.

Handle build failure

shraiysh retitled this revision from [MLIR][OpenMP] Fixed the missing inclusive clause in omp.wsloop to [MLIR][OpenMP] Fixed the missing inclusive clause in omp.wsloop and fix order clause.Oct 22 2021, 2:25 AM
shraiysh edited the summary of this revision. (Show Details)
mlir/test/Dialect/OpenMP/invalid.mlir
150

Is this an error because inclusive is not placed after ub?

158

Why is this an error?

mlir/test/Dialect/OpenMP/ops.mlir
146

Nit: Is this a formatting character?

shraiysh updated this revision to Diff 381563.Oct 22 2021, 8:37 AM

Address comments

Thanks for the comments @kiranchandramohan. I have addressed them.

mlir/test/Dialect/OpenMP/invalid.mlir
150

Yes, as you suggested, inclusive is not a clause and so, it is expected outside the clause-list. I placed it right after the upper bound because it only affects the upper bound.

158

This is an error because order(default) is not allowed to be specified by the user according to the standard. Order can either be present with the concurrent value, or it should not be there.

mlir/test/Dialect/OpenMP/ops.mlir
146

I don't think it is a formatting character, I have tried to remove it and add spaces and upload the diff, but it is staying. I believe this is just a new-line diff.

shraiysh updated this revision to Diff 381746.Oct 23 2021, 9:02 AM

Update to restart build

shraiysh updated this revision to Diff 381755.Oct 23 2021, 11:05 AM

Rebase with main

The builds have passed now. This patch is ready for review.

Thanks @shraiysh for providing those previous missed test cases.

mlir/test/Dialect/OpenMP/invalid.mlir
158

It seems that order clause can only be present with the concurrent value. Where does the OMP_ORDER_default in OMP.td come from? I don't see this in OpenMP 5.0 Spec.

shraiysh added inline comments.Oct 24 2021, 9:34 PM
mlir/test/Dialect/OpenMP/invalid.mlir
158

Yes, that is correct. It is not in the OpenMP Spec, but as far as I understand, every Clause in OMP.td is supposed to have a default value (which signifies no value, I believe). I faced a similar issue when dealing with the memory_order clause. There was no default memory clause in the standard, and not adding a default value was leading to some errors in either one of llvm/clang/flang (I don't exactly remember which one). @clementval please correct me if I have missed something.

LGTM.

mlir/test/Dialect/OpenMP/invalid.mlir
158

Thanks for the explanation. This is fine with me.

peixin accepted this revision.Oct 26 2021, 6:26 PM

I have a couple of questions.

mlir/test/Dialect/OpenMP/invalid.mlir
150

Since we have not documented the difference between regular OpenMP clauses and OpenMP dialect attributes/operands, it might be confusing to get this error. Would it be possible to give the error regarding the placement?

158

I think ClauseVal is currently only used for generating string attributes for some clauses in the OpenMP MLIR dialect. This change will list default as a possible option but the verifier will not permit it which I believe is not an ideal situation.
https://mlir.llvm.org/docs/Dialects/OpenMPDialect/#attributes-4

Can we do something else here?

  1. Since only one value is allowed can this be changed to a unit attribute?
  2. Check whether the requirement for default can be relaxed? Where did you see this error?

Thanks for the questions @kiranchandramohan ! I have tried to address them. Please let me know what you think.

mlir/test/Dialect/OpenMP/invalid.mlir
150

We can change this error message for invalid clauses in general, but changing it specifically for "inclusive" might not be simple with the current implementation. AFAIU, we have two choices -

  • Make inclusive a clause and change the syntax back to original, just for OpenMP Dialect (might be useful for other loop-related pragmas too).
  • Change the error message to include something like "attribute might be placed wrongly".
158

This error is not seen in the latest rebase. So we can use it without the default value now.

shraiysh added inline comments.Oct 27 2021, 5:41 AM
mlir/test/Dialect/OpenMP/invalid.mlir
158

I am sorry, there is an error in the latest rebase too. I do not know why procbind is getting affected by the presence/absence of default value for OMPC_Order. Looking into it.

$ ninja check-mlir
undefined reference to `llvm::omp::getProcBindKind(llvm::StringRef)'

Thanks. LGTM.

mlir/test/Dialect/OpenMP/invalid.mlir
150

OK. No need to change now. We can later handle this appropriately as an attribute in general syntax, using open-closed interval syntax etc.

158

There is an error before that which leads to the OMP*.inc files not being generated and possibly the first missing function is getProcBindKind which causes an undefined reference.

[3/41] Building OMP.inc...
error: At least one val in Clause order must be defined as default.

Looking at this again I think this is OK, we do not generate documentation for the OrderKind values. And default does not seem to be in OrderKind.

def OrderKindconcurrent : StrEnumAttrCase<"concurrent">;
def OrderKind: StrEnumAttr<
  "ClauseOrderKind",
  "OrderKind Clause",
  [OrderKindconcurrent]> {
    let cppNamespace = "::mlir::omp";
}

BTW, proc_bind uses the unknown value for this purpose. Would it be better to reuse this value (unknown) instead of default?
def OMP_PROC_BIND_unknown : ClauseVal<"unknown",7,0> { let isDefault = true; }

This revision is now accepted and ready to land.Oct 27 2021, 3:42 PM
shraiysh updated this revision to Diff 382936.Oct 28 2021, 12:27 AM

Changed default to "unknown"

mlir/test/Dialect/OpenMP/invalid.mlir
150

Okay.

158

Hi, thanks for looking into this. I will change it to unknown.