This patch adds lowering for task construct from Fortran to
omp.task operation in OpenMPDialect Dialect (mlir). Also added tests
for the same.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM. Please wait a day in case others have comments.
Nit: We generally call the step from parse-tree to MLIR lowering.
One general question: Are those clauses for task construct supported when lowering to LLVM IR? Specifically, if, final, unted, mergeable, priority, allocate clauses. If not, should we wait for those support in OMPIRBuilder and lowering from MLIR to LLVMIR. Or will there be one TODO when lowering from MLIR to LLVMIR or OMPIRBuilder?
Nit: We generally call the step from parse-tree to MLIR lowering.
+1
In addition, this reminds me that 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. For example, this patch makes private and firstprivate clauses passed. Are those two clauses supported for task construct if using the code in https://reviews.llvm.org/D122595?
Or will there be one TODO when lowering from MLIR to LLVMIR or OMPIRBuilder?
There will be an error reporting when this is encountered. It is already done in patch D123919.
For example, this patch makes private and firstprivate clauses passed.
I agree, thanks for pointing out. Would it better if we split the genOmpBlockConstruct into genOmpParallelConstruct, genOMPTaskConstruct etc.?
Would it better if we split the genOmpBlockConstruct into genOmpParallelConstruct, genOMPTaskConstruct etc.?
I think so, too. Now there are 5 constructs using the same clauses handling. I think they should be split.
Privatisation should work the same for all the block constructs. If it is not working then it is likely a bug. If there is a difference in handling the clauses depending on where it appears then we can split or parameterise a common function. Until then we can keep it the same is my opinion. But if you feel strongly then feel free to go ahead.
Privatisation should work the same for all the block constructs. If it is not working then it is likely a bug. If there is a difference in handling the clauses depending on where it appears then we can split or parameterise a common function. Until then we can keep it the same is my opinion. But if you feel strongly then feel free to go ahead.
I am also OK to this patch considering all the necessary clauses have TODOs when lowering to LLVM IR. @shraiysh Can you check if private and firstprivate works ok for task construct with this patch? If ok, can you add two test cases for them? We can delay the refactor work and discussion in D121583.
@shraiysh Can you add one test case of basic data type such as integer for private and firstprivate? I think you can move forward with this patch without the need to support complex data type for privatization. Maybe it's better to not let it block other works for task construct. Also, can you change the title and summary to "Support lowering to ..."?
flang/test/Lower/OpenMP/task.f90 | ||
---|---|---|
3 | Can you remove the fir-opt test? Also, can you remove the --check-prefixes? |
@peixin sure I will add it soon and address your comments. I was working on this but was distracted by the issue in firstprivate implementation. For the time being, I will go ahead with the current implementation of firstprivate. Also, I will edit the revision to "lowering..." for this revision, but according to MLIR terminology, "lowering" refers to changing MLIR from one dialect operation to another (input is mlir and output is also mlir), and "translation" refers to the act of "importing to mlir" or "exporting from mlir" (either input or output is not mlir). I think this terminology is confusing and we should change it in the future.
A small question though, all captured task variables are firstprivate by default. So, this will be handled like default clause was handled, right? (we need to collect all the symbols under the region and emit firstprivate code for them).
For fortran code, I think we usually use lowering for parse-tree to FIR Dialect.
A small question though, all captured task variables are firstprivate by default.
Is this implementation defined? Does clang do this? I don't find this requirement in the standard.
So, this will be handled like default clause was handled, right? (we need to collect all the symbols under the region and emit firstprivate code for them).
If this is implementation defined, I am not sure if it should be handled in lowering stage or OMPIRBuilder.
Is this implementation defined? Does clang do this? I don't find this requirement in the standard.
Ah, I must have misread this from somewhere🤦♂️. This whole time I was focusing on it. I rechecked the standard and this requirement is not there. Thank you for correcting me.
Can you remove the fir-opt test? Also, can you remove the --check-prefixes?