-
Notifications
You must be signed in to change notification settings - Fork 14k
[Flang][OpenMP] Restructure recursive lowering in createBodyOfOp
#77761
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
kparzysz
merged 14 commits into
main
from
users/kparzysz/spr/a05-complete-createBodyOfOp
Jan 22, 2024
Merged
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
62f3165
[Flang][OpenMP] Separate creation of work-sharing and SIMD loops, NFC
kparzysz 841ae5f
[Flang][OpenMP] Push genEval calls to individual operations, NFC
kparzysz 67ea0e5
[Flang][OpenMP] Handle SECTION construct from within SECTIONS
kparzysz 883afd9
[Flang][OpenMP] Push genEval closer to leaf lowering functions
kparzysz 1b5524a
[Flang][OpenMP] Restructure recursive lowering in `createBodyOfOp`
kparzysz cc411f2
Merge branch 'main' into users/kparzysz/spr/a04-geneval-in-leafs
kparzysz cb3f267
Add parameter description for genNested
kparzysz 51a9edf
Merge branch 'users/kparzysz/spr/a04-geneval-in-leafs' into users/kpa…
kparzysz a1b59bf
Add more detailed checks to testcase
kparzysz 8ead6c5
Add testcase from https://github.com/llvm/llvm-project/pull/77329
kparzysz 9394b96
Trigger new build
kparzysz 00ad95a
Merge branch 'main' into users/kparzysz/spr/a05-complete-createBodyOfOp
kparzysz 1207d60
Replace assertion with constructing unique block
kparzysz bb6795e
Update flang/lib/Lower/OpenMP.cpp
kparzysz File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
! RUN: bbc -fopenmp -o - %s | FileCheck %s | ||
|
||
! Check that this test can be lowered successfully. | ||
! See https://github.com/llvm/llvm-project/issues/74348 | ||
|
||
! CHECK-LABEL: func.func @_QPsb | ||
! CHECK: omp.parallel | ||
! CHECK: cf.cond_br %{{[0-9]+}}, ^bb1, ^bb2 | ||
! CHECK-NEXT: ^bb1: // pred: ^bb0 | ||
! CHECK: cf.br ^bb2 | ||
! CHECK-NEXT: ^bb2: // 3 preds: ^bb0, ^bb1, ^bb2 | ||
! CHECK-NEXT: cf.br ^bb2 | ||
! CHECK-NEXT: } | ||
|
||
subroutine sb(ninter, numnod) | ||
integer :: ninter, numnod | ||
integer, dimension(:), allocatable :: indx_nm | ||
|
||
!$omp parallel | ||
if (ninter>0) then | ||
allocate(indx_nm(numnod)) | ||
endif | ||
220 continue | ||
goto 220 | ||
!$omp end parallel | ||
end subroutine |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
! RUN: bbc -emit-hlfir -fopenmp -o - %s | FileCheck %s | ||
|
||
subroutine sub(imax, jmax, x, y) | ||
integer, intent(in) :: imax, jmax | ||
real, intent(in), dimension(1:imax, 1:jmax) :: x, y | ||
|
||
integer :: i, j, ii | ||
|
||
! collapse(2) is needed to reproduce the issue | ||
!$omp parallel do collapse(2) | ||
do j = 1, jmax | ||
do i = 1, imax | ||
do ii = 1, imax ! note that this loop is not collapsed | ||
if (x(i,j) < y(ii,j)) then | ||
! exit needed to force unstructured control flow | ||
exit | ||
endif | ||
enddo | ||
enddo | ||
enddo | ||
end subroutine sub | ||
|
||
! this is testing that we don't crash generating code for this: in particular | ||
! that all blocks are terminated | ||
|
||
! CHECK-LABEL: func.func @_QPsub( | ||
! CHECK-SAME: %[[VAL_0:.*]]: !fir.ref<i32> {fir.bindc_name = "imax"}, | ||
! CHECK-SAME: %[[VAL_1:.*]]: !fir.ref<i32> {fir.bindc_name = "jmax"}, | ||
! CHECK-SAME: %[[VAL_2:.*]]: !fir.ref<!fir.array<?x?xf32>> {fir.bindc_name = "x"}, | ||
! CHECK-SAME: %[[VAL_3:.*]]: !fir.ref<!fir.array<?x?xf32>> {fir.bindc_name = "y"}) { | ||
! [...] | ||
! CHECK: omp.wsloop for (%[[VAL_53:.*]], %[[VAL_54:.*]]) : i32 = ({{.*}}) to ({{.*}}) inclusive step ({{.*}}) { | ||
! [...] | ||
! CHECK: cf.br ^bb1 | ||
! CHECK: ^bb1: | ||
! CHECK: cf.br ^bb2 | ||
! CHECK: ^bb2: | ||
! [...] | ||
! CHECK: cf.br ^bb3 | ||
! CHECK: ^bb3: | ||
! [...] | ||
! CHECK: %[[VAL_63:.*]] = arith.cmpi sgt, %{{.*}}, %{{.*}} : i32 | ||
! CHECK: cf.cond_br %[[VAL_63]], ^bb4, ^bb7 | ||
! CHECK: ^bb4: | ||
! [...] | ||
! CHECK: %[[VAL_76:.*]] = arith.cmpf olt, %{{.*}}, %{{.*}} fastmath<contract> : f32 | ||
! CHECK: cf.cond_br %[[VAL_76]], ^bb5, ^bb6 | ||
! CHECK: ^bb5: | ||
! CHECK: cf.br ^bb7 | ||
! CHECK: ^bb6: | ||
! [...] | ||
! CHECK: cf.br ^bb3 | ||
! CHECK: ^bb7: | ||
! CHECK: omp.yield | ||
! CHECK: } | ||
! CHECK: omp.terminator | ||
! CHECK: } | ||
! CHECK: cf.br ^bb1 | ||
! CHECK: ^bb1: | ||
! CHECK: return | ||
! CHECK: } |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it guaranteed that it is only when there is an infinite loop that no exit block exists?
Also who/what inserts the terminator for this case (when there is infinite loop)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We rely on the
genEval
for the nested code to do its thing. If we consider the nested code (PFT/Evaluation) on its own, it will have a single entry point, and zero or more exit points. If it creates multiple blocks, it will need to create its own branches to facilitate the control flow. AftergenEval
we remove the temporary terminator, then we look at all the blocks created duringgenEval
. We know that everything that is present inside of these blocks was created for the nested code (and not the enclosing construct we're lowering). Terminators for our op haven't been created yet, and they can only placed in blocks that don't yet have a terminator. If every block has a terminator then there is no way to leave the region by means of reaching the end of it (that is aside from function calls).Based on that, the logical thing to do would be to insert a terminator into all non-terminated blocks. This would work even if there is always at most one such block.
The assertion that there can only be one comes mostly from two things:
If we can't be sure that the assertion is correct, we should be able to remove it, and process all exiting blocks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm going to do is to create a unique exiting block: create a new block, and for each yet-unterminated block, will insert a branch to the new one. Then insert the OMP terminator into it, and process the lastprivate in there.
This will get rid of the assertion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Makes sense.