This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][OpenMP] Added parseClauses
ClosedPublic

Authored by shraiysh on Sep 30 2021, 9:41 PM.

Details

Summary

Code reorganized in OpenMPDialect.cpp to have all functions corresponding to an operation together.

Added parseClauses function to avoid code duplication while parsing clauses in OpenMP operations. Also added printers and verifiers for clauses, which are being used for multiple operations.

Diff Detail

Event Timeline

shraiysh created this revision.Sep 30 2021, 9:41 PM
shraiysh requested review of this revision.Sep 30 2021, 9:41 PM
shraiysh edited the summary of this revision. (Show Details)Sep 30 2021, 9:46 PM
clementval added inline comments.Oct 1 2021, 12:44 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
203

Usually you don't need to specify the number of inlined elements unless you have a good reason for it. Same for the other SmallVector below.

shraiysh updated this revision to Diff 376801.Oct 3 2021, 8:49 PM

Addressed comments

shraiysh marked an inline comment as done.Oct 3 2021, 8:50 PM
clementval added inline comments.Oct 5 2021, 5:24 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
238

I don't see any use of the allowRepeat in the clauses below. Is that correct. Clauses like private and other data related clauses are usually allowed multiple times.

shraiysh added inline comments.Oct 5 2021, 5:52 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
238

Yes, that is correct. I have not used it anywhere. Earlier an allowedOnce function was used to make sure that there is only one private clause (similarly for others). There are a few invalid.mlir testcases for this too. Personally, I have no preference for either because they can always be clubbed into one. Please let me know if I should change this to allow repetition.

Is there a reason that WsLoopOp has been moved? It makes it harder to see the differences.

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

[style] LLVM's coding style does bit use almost-always-auto

195–197
236

[suggestion] This enum and the parsing of the clauses looks like something that could be generated from the .td. No idea whether it is worth it, but would allow to just add another clause into the td and re-use one of the parsers, e.g. a simple int argument.

clementval added inline comments.Oct 11 2021, 10:52 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
236

+1

Thank you for the review Michael.

The reason for moving the builders and verifier for WsLoopOp is that earlier the parser, printer, verifier and builders for WsLoopOp were all scattered throughout the file. Now they are together. It might be easier to review the file separately, instead of the diff. Here is a brief structure of the file now:

// Parsers and printers for individual clauses...
//
// The function parseClauses.
//
// ParallelOp
//    parseParallelOp calls parseClauses
//
// WsLoopOp
//    parseWsLoopOp calls parseClauses
//
// ReductionOp
//
// CriticalOp
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
236

Thanks for the suggestion Michael and Valentin. I wanted to make sure if I understood it properly.

  1. The clauses should be defined in the OpenMPOps.td file and parsers for clause-list in directives should be generated using TableGen (by adding a function in DirectiveCommonGen.cpp).
  2. The parsers for individual clauses like one with a simple int argument will be defined in OpenMPDialect.cpp, which can then be re-used for other clauses too.

Is that correct?

clementval added inline comments.Oct 13 2021, 4:21 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
236

The clause are already defined in the file llvm/include/llvm/Frontend/OpenMP/OMP.td and they should not be defined anywhere else if possible.
The DirectiveCommonGen.cpp is the right place to generate code for MLIR related files from OMP.td.

shraiysh added inline comments.Oct 13 2021, 5:54 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
236

Thanks Valentin. The generation of these parsers will require the number of variadic operands for every clause, because they have to be added to the operand_segment_sizes attribute. I think that it has to be added as another field to the clauses in OMP.td as mlirSegments. Any suggestions for better alternatives to this would be helpful.

Thank you for the review Michael.

The reason for moving the builders and verifier for WsLoopOp is that earlier the parser, printer, verifier and builders for WsLoopOp were all scattered throughout the file. Now they are together. It might be easier to review the file separately, instead of the diff. Here is a brief structure of the file now:

// Parsers and printers for individual clauses...
//
// The function parseClauses.
//
// ParallelOp
//    parseParallelOp calls parseClauses
//
// WsLoopOp
//    parseWsLoopOp calls parseClauses
//
// ReductionOp
//
// CriticalOp

Would it be possible to retain the existing ordering and move to the new ordering in a separate NFC patch which you can submit without review? The old ordering will help to review.

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

In my personal opinion, let us do autogen in a separate patch after winding up the discussion on extending ODS.

shraiysh updated this revision to Diff 379373.Oct 13 2021, 7:28 AM

Preserving old ordering for easier review. Addressed comments.

shraiysh marked an inline comment as done.Oct 13 2021, 7:28 AM
shraiysh updated this revision to Diff 379380.Oct 13 2021, 7:52 AM

Fixed Formatting error

shraiysh updated this revision to Diff 379657.Oct 14 2021, 4:13 AM

Rebase with main

Ping!

I am reviewing this patch today.

Nice reorganization.

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

Prints -> Print?

151

Prints -> Print?

178–179

Why not move printDataVars out? Maybe adding two static functions printDataVars and printOperandAndTypeList is better?

231

It seems that op is not used.

286

"op" is not used.

503

Would it be better to use switch-case statement instead of if-else statement?

656–681

rection -> reduction.

769

Delete the line 764. Declare the variable when it is used.
-> int numIVs = static_cast<int>(ivs.size());

770

Move the line 764 to here.

798

Delte the blank line 802 and 804.

816–817

printDataVars can be moved out. It's the same as the one above.

Looks good. Thanks for this re-organization. A few minor comments.

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

Is this assert necessary here? This is caught by the verifier right?

656–681

Nit: rection -> reduction

822

Nit: Can the printing of linear, schedule be moved into the printLinearClause or printScheduleClause function? Or alternatively, can the printing of reduction be moved out of printReductionVarList?

mlir/test/Dialect/OpenMP/invalid.mlir
4

Why is this shortened?

shraiysh updated this revision to Diff 380614.Oct 19 2021, 2:08 AM
shraiysh marked 15 inline comments as done.

Thanks for the reviews @peixin @kiranchandramohan . Addressed comments.

@peixin I have mentioned the motivation for putting the op argument in some functions. Please let me know if they should be removed.

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

The motivation for doing this was to allow using custom<LinearClause> in assemblyFormat (if required) later. It makes the prototypes of print**Clause functions uniform. Let me know if you want me to remove the argument op.

286

Same reason. Let me know if this needs to be removed.

326

Yes, that is correct. Removed it. Thanks for pointing this out.

503

Normal switch case is not supported on StringRefs. I am not aware of another way to switch case cleanly on strings. If there is a way, please let me know, I will modify the code accordingly.

mlir/test/Dialect/OpenMP/invalid.mlir
4

This is because invalid is not a recognized clause. If it were simply not allowed for omp.parallel but still a valid clause, the error would be the same as before.

peixin added inline comments.Oct 19 2021, 2:16 AM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
231

If so, no need to remove it. Maybe add one comment to describe it?

503

Got it. Keep the current style.

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

If it results in an unused warning then some builders/CI will fail. It seems MLIR is built with -Wno-unused-parameter and hence there is no Warning.

mlir/test/Dialect/OpenMP/invalid.mlir
4

I might be missing a point here, the error that is emitted seems to be the same as before.

error: custom op 'omp.parallel' invalid is not a valid clause for the omp.parallel operation
  omp.parallel invalid {
  ^
shraiysh updated this revision to Diff 380624.Oct 19 2021, 2:55 AM
shraiysh marked 6 inline comments as done.

Thanks for the comments @kiranchandramohan @peixin.

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

Oh okay then, I will remove unused parameters.

mlir/test/Dialect/OpenMP/invalid.mlir
4

Hmm this is weird, it doesn't seem to give this error in my build. There are two errors,

  • invalid is supposed to go to final else in the while loop (inside parseClauses) and emit the error, invalid is not a valid clause.
  • The other case will be when lastprivate is used with ParallelOp (which emits the error from checkAllowed). That should give the error lastprivate is not a valid clause for the omp.parallel operation.

Should I make them the same message to avoid such confusion?

LGTM. Thanks once again for this cleanup.

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

Nit: Please remove. If required for assembly format, we can re-introduce.

mlir/test/Dialect/OpenMP/invalid.mlir
4

Sorry, this was an issue in my build. I was building flang which does not build mlir-opt. Ignore.

This revision is now accepted and ready to land.Oct 19 2021, 3:04 AM
peixin accepted this revision.Oct 19 2021, 4:36 AM

LGTM.

shraiysh marked 2 inline comments as done.Oct 19 2021, 4:42 AM

Thanks for the review @kiranchandramohan @peixin. I will land this now.

This revision was automatically updated to reflect the committed changes.

@shraiysh This patch seems to make the test cases in https://reviews.llvm.org/D110015 failed. The following MLIR can be generated from the fortran code using bbc on fir-dev.

subroutine test()
  integer:: i, N = 10
  !$omp do ordered(1)
  do i = 2, N
  end do
  !$omp end do
end subroutine
func @_QPtest() {
  %c2_i32 = constant 2 : i32
  %c1_i32 = constant 1 : i32
  %0 = fir.alloca i32 {bindc_name = "i", uniq_name = "_QFtestEi"}
  %1 = fir.address_of(@_QFtestEn) : !fir.ref<i32>
  %2 = fir.load %1 : !fir.ref<i32>
  omp.wsloop (%arg0) : i32 = (%c2_i32) to (%2) step (%c1_i32) ordered(1) inclusive {
    omp.yield
  }
  return
}
fir.global internal @_QFtestEn : i32 {
  %c10_i32 = constant 10 : i32
  fir.has_value %c10_i32 : i32
}

After this PR, the inclusive attribute in the above MLIR seems to be an invalid clause. Do I miss something or understand it incorrectly?

peixin added inline comments.Oct 20 2021, 8:44 PM
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
795

Is inclusive missed here?

@shraiysh This patch seems to make the test cases in https://reviews.llvm.org/D110015 failed. The following MLIR can be generated from the fortran code using bbc on fir-dev.

subroutine test()
  integer:: i, N = 10
  !$omp do ordered(1)
  do i = 2, N
  end do
  !$omp end do
end subroutine
func @_QPtest() {
  %c2_i32 = constant 2 : i32
  %c1_i32 = constant 1 : i32
  %0 = fir.alloca i32 {bindc_name = "i", uniq_name = "_QFtestEi"}
  %1 = fir.address_of(@_QFtestEn) : !fir.ref<i32>
  %2 = fir.load %1 : !fir.ref<i32>
  omp.wsloop (%arg0) : i32 = (%c2_i32) to (%2) step (%c1_i32) ordered(1) inclusive {
    omp.yield
  }
  return
}
fir.global internal @_QFtestEn : i32 {
  %c10_i32 = constant 10 : i32
  fir.has_value %c10_i32 : i32
}

After this PR, the inclusive attribute in the above MLIR seems to be an invalid clause. Do I miss something or understand it incorrectly?

Ah! Sorry for this. It is a small error with this patch. I have marked it as an inline comment. I will submit a differential (along with the tests in llvm/main) correcting this error in sometime.

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

There should be inclusiveClause in this list. It is not.

Ah! Sorry for this. It is a small error with this patch. I have marked it as an inline comment. I will submit a differential (along with the tests in llvm/main) correcting this error in sometime.

Thanks @shraiysh for the confirmation.

@kiranchandramohan Should I revert https://reviews.llvm.org/rGdc2be87ecf10f2f1cf05f638a72256387c78f1c1 now and land it again after this bug is fixed since current ninja-check-mlir have three failed test cases?

If it is okay with you, I will check those test cases while pushing my fix. I will rebase with latest main (along with https://reviews.llvm.org/D110015 ) and run tests to avoid such issues. We might not have to revert it, but I understand if you want to revert it.

@shraiysh Sure. Please go ahead and check those test cases with your fix. Please give this fix high priority since current llvm-project cannot pass CI successfully since our patches.

Yes, I have added the revision D112198. Once the builds pass, and the reviewers accept it, I will land it. Once again, apologies for this!

Ah! Sorry for this. It is a small error with this patch. I have marked it as an inline comment. I will submit a differential (along with the tests in llvm/main) correcting this error in sometime.

Thanks @shraiysh for the confirmation.

@kiranchandramohan Should I revert https://reviews.llvm.org/rGdc2be87ecf10f2f1cf05f638a72256387c78f1c1 now and land it again after this bug is fixed since current ninja-check-mlir have three failed test cases?

In this case you should revert your patch if you cannot fix it directly. There is no problem to land it again later when the problem is fixed.

In this case you should revert your patch if you cannot fix it directly. There is no problem to land it again later when the problem is fixed.

@clementval Got it. Thanks for the explanations.

In this case you should revert your patch if you cannot fix it directly. There is no problem to land it again later when the problem is fixed.

@clementval Got it. Thanks for the explanations.

I know it's not always easy since some buildbot have quite some delays between the commit and the actual build. Anyway if it's really a blocker someone will revert it for you.