This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP][Flang][MLIR] Lowering of OpenMP requires directive from parse tree to MLIR
ClosedPublic

Authored by skatrak on Mar 30 2023, 4:42 AM.

Details

Summary

This patch implements the lowering of the OpenMP 'requires' directive from Flang parse tree to MLIR attributes attached to the top-level module.

Target-related 'requires' clauses are gathered and combined for each top-level unit during semantics. Lastly, a single module-level omp.requires attribute is attached to the MLIR module with that information at the end of the process.

The atomic_default_mem_order clause is not addressed by this patch, but rather it will come as a separate patch and follow a different approach.

Depends on D147214, D150328, D150329 and D157983.

Diff Detail

Event Timeline

skatrak created this revision.Mar 30 2023, 4:42 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
skatrak requested review of this revision.Mar 30 2023, 4:42 AM
skatrak planned changes to this revision.Apr 19 2023, 7:48 AM

Currently working on making sure that the omp.requires and omp.atomic_default_mem_order attributes are only attached to the module if the -fopenmp flag is set. Also make sure there's device code (via target region or declare target) in the compilation unit for the omp.requires attribute to be attached to the module.

skatrak updated this revision to Diff 515720.Apr 21 2023, 6:53 AM

Update tests, and only attach omp.requires attribute if there is device code
in the module (i.e. target region or declare target device_type=device|any).

skatrak updated this revision to Diff 516340.Apr 24 2023, 3:14 AM

Remove leftover TODO.

skatrak updated this revision to Diff 516353.Apr 24 2023, 4:35 AM

Reduce extent of refactoring to prevent merge conflicts.

skatrak updated this revision to Diff 516719.Apr 25 2023, 2:43 AM

Update with latest changes to parent patch.

skatrak updated this revision to Diff 516729.Apr 25 2023, 3:09 AM

Try to fix issue with applying patch

Herald added a reviewer: ftynse. · View Herald Transcript
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald Transcript
skatrak updated this revision to Diff 516730.Apr 25 2023, 3:12 AM

Try undoing last change.

skatrak updated this revision to Diff 517616.Apr 27 2023, 9:52 AM

Remove checks from lowering that belong in semantic analysis

skatrak updated this revision to Diff 517844.Apr 28 2023, 2:14 AM

Remove leftover unit test

skatrak updated this revision to Diff 518698.May 2 2023, 6:10 AM

Rebase. Disable some known failing 'declare target' tests temporarily until they are fixed by parent patch.

skatrak updated this revision to Diff 520337.May 8 2023, 5:58 AM

Remove handling of atomic_default_mem_order, as it's now done in semantics. Fix conflicts with changes to parent patch.

TIFitis added inline comments.May 26 2023, 5:16 AM
flang/lib/Lower/OpenMP.cpp
2254

This seems to be the only function name with the 'handle' prefix. Maybe rename it to something like genDeclareTarget ?

2265

Remove use of auto here.

Also in other places if the type isn't immediately discernible then consider naming the type.

skatrak updated this revision to Diff 527354.Jun 1 2023, 4:03 AM

Rebase and address reviewer's comments.

skatrak marked 2 inline comments as done.Jun 1 2023, 4:22 AM

Thank you for the comments, they should have all been addressed now.

TIFitis accepted this revision.Jun 2 2023, 12:05 PM

LGTM

This revision is now accepted and ready to land.Jun 2 2023, 12:05 PM
flang/lib/Lower/Bridge.cpp
271

Is this set anywhere? If not is it required? Can this be made available through the bridge?

2075

Can this function be moved to OpenMP.cpp?

Thank you for the feedback. I expect I will be able to refactor the analyzeOpenMPDeclarative() function to OpenMP.cpp as suggested, but I'll bring that together with other changes to make it integrate cleanly with the latest changes to D149337. Since that patch now moves a big part of the gathering of 'requires' clauses to the prior semantics step, this patch can be simplified to rely on that.

flang/lib/Lower/Bridge.cpp
271

The ompRequiresFlags field is set by the analyzeOpenMPDeclarative method, called for each 'omp requires' directive in the PFT.

I'm not sure if I understand what you mean by making this available through the bridge. Do you suggest creating a public method to access these flags?

skatrak updated this revision to Diff 531437.Jun 14 2023, 11:28 AM

Update patch to integrate with related patch D149337 and address reviewer's comments.

skatrak requested review of this revision.Jun 14 2023, 11:33 AM

Changing status to "Request Review" again due to some significant changes to the approach.

skatrak updated this revision to Diff 531717.Jun 15 2023, 5:48 AM

Rebasde to fix build error.

skatrak updated this revision to Diff 534512.Jun 26 2023, 5:36 AM

Update to integrate with changes to parent patch.

skatrak edited the summary of this revision. (Show Details)Jun 29 2023, 5:46 AM
skatrak updated this revision to Diff 551113.Aug 17 2023, 6:25 AM

Change parent and update patch.

skatrak updated this revision to Diff 551500.Aug 18 2023, 7:13 AM

Rebase and address conflicts.

skatrak updated this revision to Diff 552411.Aug 22 2023, 9:43 AM
skatrak marked an inline comment as done.

Update patch.

skatrak updated this revision to Diff 556436.Sep 11 2023, 8:18 AM

Update patch. Ping for review and unblocking remaining accepted REQUIRES patches, thank you!

Could you add to the summary that the atomic related handling is done elsewhere.

Could you expand the tests to cover the various if conditions that are used in the code?

flang/include/flang/Lower/OpenMP.h
16

Is this include required here?

flang/lib/Lower/Bridge.cpp
306

Is this handling required for Block Data? If so, could you add a test?

4149

If this is specific for device code, might be worth renaming it to something specific to device.

skatrak edited the summary of this revision. (Show Details)Sep 12 2023, 3:16 AM
skatrak updated this revision to Diff 556542.Sep 12 2023, 3:23 AM
skatrak marked 3 inline comments as done.

Address review comments.

Thank you Kiran for having a look at this!

Could you add to the summary that the atomic related handling is done elsewhere.

Done.

Could you expand the tests to cover the various if conditions that are used in the code?

I created a test to gather the flags from the symbol for a FunctionLikeUnit and for a BlockDataUnit, and checked that these flags are only added for the module when there's a device construct in the compilation unit, regardless of whether we're compiling for host or device and whether the device construct is a target region or a declare target subroutine. I think that covers all main aspects of this patch.

I have also detected that there is a situation where this approach doesn't currently work, so I created an expected-fail test for unnamed block data. The issue is that there is no symbol created for those, so there's nowhere to store/find these flags. I have seen this happen for main programs as well, but I've not been able to create a reproducer for which that happened that contained device constructs. In my opinion, this edge case should be addressed as its own patch.

flang/include/flang/Lower/OpenMP.h
16

It was, but only because I had made public a function that wasn't supposed to be, thanks for noticing.

flang/lib/Lower/Bridge.cpp
4149

This is for both host and device, it's just that it's only generated if there are device constructs in the compilation unit. Let me know if you still suggest renaming it to something else.

I modified the unit tests to run them for the target device as well, so that it's clear that the same behavior is expected.

skatrak updated this revision to Diff 556543.Sep 12 2023, 3:42 AM

Remove leftover comment.

LG.

flang/lib/Lower/Bridge.cpp
2127–2128

Can this be rewritten this way.

And rename analyzeOpenMPDeclarativeConstruct to isTargetDeclare or something like that?

This revision is now accepted and ready to land.Sep 12 2023, 7:51 AM

Thank you for the review. After I address your last comment my plan is to land this and the other two accepted REQUIRES patches that depended on it.

Is there a preferred approach as to how to go about it? I could rebase them all and wait until the pre-merge builds finish without errors and then land them in quick succession or I could go one by one to make sure post-merge builds don't find any issues before landing the next, which will be over a couple of days most likely.

flang/lib/Lower/Bridge.cpp
2127–2128

My idea was to make it generic to allow the analysis of other declarative constructs in the future there as well, that's the reason for the function name and returning through an output argument. But I'll follow your suggestion, since we don't know for sure that we'll need this later on.

Thank you for the review. After I address your last comment my plan is to land this and the other two accepted REQUIRES patches that depended on it.

Is there a preferred approach as to how to go about it? I could rebase them all and wait until the pre-merge builds finish without errors and then land them in quick succession or I could go one by one to make sure post-merge builds don't find any issues before landing the next, which will be over a couple of days most likely.

Both are fine. I would recommend the former.

skatrak updated this revision to Diff 556655.Sep 13 2023, 5:23 AM

Rebase and address review comment.

skatrak marked an inline comment as done.Sep 13 2023, 5:24 AM