This patch separates clause translation from direction translation while converting F90 to OpenMP Dialect. This clause handler can be reused for other operations like wsloop, sections etc.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
flang/lib/Lower/OpenMP.cpp | ||
---|---|---|
130 | The name is a bit misleading. Something with OpenMP in the name would make more sense IMO. |
flang/lib/Lower/OpenMP.cpp | ||
---|---|---|
130 | How about removing MLIR? OpenMPClauses or OmpClauses? | |
134 | We used someClauseOperand(s) for other constructs in OpenMP.cpp in fir-dev. Can we keep consistent with others? | |
137 | handleProcBindClause -> genProcBindClause to be consistent with other function names in this file. |
Thanks @peixin for the comments. I will rework on this once upstreaming of translations has been done. My plan is to remove individual clause handling from genOMP functions and put it in a collect() function so all the constructs can use it. I will ping this thread once the upstreaming is done.
flang/test/Lower/OpenMP/parallel.f90 | ||
---|---|---|
2 ↗ | (On Diff #416169) | I am thinking if flang_fc1 -fopenmp -emit-fir should be added. Check the comment in https://reviews.llvm.org/D122595. Also you can check the discussions in https://reviews.llvm.org/D121171#3370137. If new passes is added in flang-new, I am not sure if it will crash the test cases. |
16 ↗ | (On Diff #416169) | Please add CHECK-LABEL for each subroutine. |
flang/lib/Lower/OpenMP.cpp | ||
---|---|---|
207 | As I mentioned in D124138, there is one drawback collecting clauses in one place for all block constructs. For those unsupported clauses, one hard TODO is changed into one unknown result, maybe one segfault. It is easy to omit some features support and get users into trouble if there is segfault/ICE. Can we let each construct have their own collect? Here is my recomendation: struct OpenMPMLIRClauses { void genNumThreadsClause( const Fortran::parser::OmpClause &clause, mlir::Value &mlirNumThreadsExpr) void genIFClause(...) ... } if (blockDirective.v == llvm::omp::OMPD_parallel) { for (const Fortran::parser::OmpClause &clause : clauseList.v) { genNumThreadsClause(...); ! if lowering to LLVM IR has been supported. genIfClause(...); ! if lowering to LLVM IR has been supported. TODO(... clause unsupported for parallel construct); } ... } else if (blockDirective.v == llvm::omp::OMPD_master) { As we pursue the OpenMP standard, it is easily know what are not supported yet. And this refector patch won't need to wait for other patches. |
@shraiysh Can you restart this work? There are two small patches left to upstream and it won't be affected too much.
To refactor the code, there are several things that I can think of to handle:
- Explicit clauses for each construct. One unsupported clause should be given one TODO.
- The clauses which are not allowed in directives should be given one assert?
- The combined constructs are not carefully organized.
flang/lib/Lower/OpenMP.cpp | ||
---|---|---|
207 | I take this back. This cause the code duplication. |
Sure @peixin, thank you for pinging here. I will restart this work soon and try to incorporate your ideas and concerns.
Hi @shraiysh, @peixin. I just realized about this patch, thanks to @kiranchandramohan, after I spent time working on a patch with basically the same goal of refactoring the clause processing in the PFT to MLIR lowering. The other patch is here: D155981.
It follows a slightly different approach where there is no collect() method or state to be kept, so the responsibility of deciding which clauses to generate code for is down to the caller. I am interested to see if you have any comments to improve that approach before landing it. It does other nonfunctional changes apart from extracting the clause-processing logic into a class, so the diff can be a bit noisy.
The name is a bit misleading. Something with OpenMP in the name would make more sense IMO.