This is an archive of the discontinued LLVM Phabricator instance.

[flang][OpenMP] Lowering for task construct
ClosedPublic

Authored by shraiysh on Apr 20 2022, 6:19 PM.

Details

Summary

This patch adds lowering for task construct from Fortran to
omp.task operation in OpenMPDialect Dialect (mlir). Also added tests
for the same.

Diff Detail

Event Timeline

shraiysh created this revision.Apr 20 2022, 6:19 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
shraiysh requested review of this revision.Apr 20 2022, 6:19 PM

LGTM. Please wait a day in case others have comments.

Nit: We generally call the step from parse-tree to MLIR lowering.

This revision is now accepted and ready to land.Apr 24 2022, 8:20 AM

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.

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?

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.

peixin added a comment.May 7 2022, 1:03 AM

@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
2

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).

shraiysh updated this revision to Diff 427908.May 7 2022, 11:55 PM
shraiysh marked an inline comment as done.

Addressed comments

shraiysh retitled this revision from [flang][OpenMP] Translation for task construct to [flang][OpenMP] Lowering for task construct.May 7 2022, 11:56 PM
shraiysh edited the summary of this revision. (Show Details)
peixin added a comment.May 8 2022, 6:28 AM

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.

shraiysh updated this revision to Diff 427941.May 8 2022, 8:56 AM

Added private clauses in multiple clauses test

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.

peixin accepted this revision.May 8 2022, 9:22 AM

LGTM

This revision was landed with ongoing or failed builds.May 9 2022, 10:12 PM
This revision was automatically updated to reflect the committed changes.