[OpenMP] Predetermined rules for loop index variables #962
Conversation
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
ichoyjx
requested review from
DavidTruby,
sscalpone,
jeanPerier,
tskeith,
klausler and
psteinfeld
sscalpone
reviewed
Feb 4, 2020
lib/semantics/resolve-names.cpp
Outdated
| std::size_t GetAssociatedLoopLevelFromClauses(const parser::OmpClauseList &); | ||
|
|
||
| template<typename T> | ||
| std::optional<std::int64_t> GetClauseIntValue(const T &x) { |
There was a problem hiding this comment.
Is there a similar routine somewhere else that does this?
There was a problem hiding this comment.
I searched around and didn't find one.
There was a problem hiding this comment.
Why not ToInt64(EvaluateIntExpr(x))?
There was a problem hiding this comment.
Yes, it works too. I can remove this template function then.
jeanPerier
reviewed
Feb 4, 2020
| AddToContextObjectWithDSA(*symbol, ivDSA); | ||
|
|
||
| const auto &block{std::get<parser::Block>(loop->t)}; | ||
| const auto it{block.begin()}; |
There was a problem hiding this comment.
Is it possible to have OMP directives on the inner loops that would break the assumption that the next inner do loop is the first element of the block list of statements ?
There was a problem hiding this comment.
Yes. The Spec requires that all the associated do-loops should be perfectly nested (no code or OpenMP directive in between). Ideally, the OpenMP structural checker will be able to capture this kind of error prior to Name Resolution.
psteinfeld
approved these changes
Feb 4, 2020
jeanPerier
approved these changes
Feb 5, 2020
|
|
||
| if (orderedLevel && (!collapseLevel || orderedLevel >= collapseLevel)) { | ||
| return orderedLevel; | ||
| } else if (!orderedLevel && collapseLevel) { |
There was a problem hiding this comment.
Sorry for not raising this yesterday, I think you could add a comment here that the case orderedLevel < collapseLevel is an error handled in omp structural checks.
This refers to three rules in OpenMP 4.5 Spec 2.15.1.1:
* The loop iteration variable(s) in the associated do-loop(s) of a do,
parallel do, taskloop, or distribute construct is (are) private.
* The loop iteration variable in the associated do-loop of a simd
construct with just one associated do-loop is linear with a linear-step
that is the increment of the associated do-loop.
* The loop iteration variables in the associated do-loops of a simd
construct with multiple associated do-loops are lastprivate.
A simple example:
```
implicit none
integer :: N = 1024
integer i, j, k
!$omp parallel do collapse(3)
do i=1, N <- i is private
do j=1, N <- j is private
do k=1, N <- k is private
enddo
enddo
enddo
end
```
If `collapse` clause is not present, the associated do-loop for construct
`parallel do` is only `i` loop. With `collapse(n)`, `i`, `j`, and `k` are
all associated do-loops and the loop index variables are private to the
OpenMP construct:
```
implicit none
!DEF: /MainProgram1/n ObjectEntity INTEGER(4)
integer :: n = 1024
!DEF: /MainProgram1/i ObjectEntity INTEGER(4)
!DEF: /MainProgram1/j ObjectEntity INTEGER(4)
!DEF: /MainProgram1/k ObjectEntity INTEGER(4)
integer i, j, k
!$omp parallel do collapse(3)
!DEF: /MainProgram1/Block1/i (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do i=1,n
!DEF: /MainProgram1/Block1/j (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do j=1,n
!DEF: /MainProgram1/Block1/k (OmpPrivate) HostAssoc INTEGER(4)
!REF: /MainProgram1/n
do k=1,n
end do
end do
end do
end program
```
This implementation assumes that the structural checks for do-loops
are done at this point, for example the `n` in `collapse(n)` should
be no more than the number of actual perfectly nested do-loops, etc..
CarolineConcatto
pushed a commit
to CarolineConcatto/f18
that referenced
this pull request
Feb 14, 2020
…#962) This refers to three rules in OpenMP 4.5 Spec 2.15.1.1: * The loop iteration variable(s) in the associated do-loop(s) of a do, parallel do, taskloop, or distribute construct is (are) private. * The loop iteration variable in the associated do-loop of a simd construct with just one associated do-loop is linear with a linear-step that is the increment of the associated do-loop. * The loop iteration variables in the associated do-loops of a simd construct with multiple associated do-loops are lastprivate. A simple example: ``` implicit none integer :: N = 1024 integer i, j, k !$omp parallel do collapse(3) do i=1, N <- i is private do j=1, N <- j is private do k=1, N <- k is private enddo enddo enddo end ``` If `collapse` clause is not present, the associated do-loop for construct `parallel do` is only `i` loop. With `collapse(n)`, `i`, `j`, and `k` are all associated do-loops and the loop index variables are private to the OpenMP construct: ``` implicit none !DEF: /MainProgram1/n ObjectEntity INTEGER(4) integer :: n = 1024 !DEF: /MainProgram1/i ObjectEntity INTEGER(4) !DEF: /MainProgram1/j ObjectEntity INTEGER(4) !DEF: /MainProgram1/k ObjectEntity INTEGER(4) integer i, j, k !$omp parallel do collapse(3) !DEF: /MainProgram1/Block1/i (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do i=1,n !DEF: /MainProgram1/Block1/j (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do j=1,n !DEF: /MainProgram1/Block1/k (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do k=1,n end do end do end do end program ``` This implementation assumes that the structural checks for do-loops are done at this point, for example the `n` in `collapse(n)` should be no more than the number of actual perfectly nested do-loops, etc..
swift-ci
pushed a commit
to swiftlang/llvm-project
that referenced
this pull request
Apr 9, 2020
…compiler/f18#962) This refers to three rules in OpenMP 4.5 Spec 2.15.1.1: * The loop iteration variable(s) in the associated do-loop(s) of a do, parallel do, taskloop, or distribute construct is (are) private. * The loop iteration variable in the associated do-loop of a simd construct with just one associated do-loop is linear with a linear-step that is the increment of the associated do-loop. * The loop iteration variables in the associated do-loops of a simd construct with multiple associated do-loops are lastprivate. A simple example: ``` implicit none integer :: N = 1024 integer i, j, k !$omp parallel do collapse(3) do i=1, N <- i is private do j=1, N <- j is private do k=1, N <- k is private enddo enddo enddo end ``` If `collapse` clause is not present, the associated do-loop for construct `parallel do` is only `i` loop. With `collapse(n)`, `i`, `j`, and `k` are all associated do-loops and the loop index variables are private to the OpenMP construct: ``` implicit none !DEF: /MainProgram1/n ObjectEntity INTEGER(4) integer :: n = 1024 !DEF: /MainProgram1/i ObjectEntity INTEGER(4) !DEF: /MainProgram1/j ObjectEntity INTEGER(4) !DEF: /MainProgram1/k ObjectEntity INTEGER(4) integer i, j, k !$omp parallel do collapse(3) !DEF: /MainProgram1/Block1/i (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do i=1,n !DEF: /MainProgram1/Block1/j (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do j=1,n !DEF: /MainProgram1/Block1/k (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do k=1,n end do end do end do end program ``` This implementation assumes that the structural checks for do-loops are done at this point, for example the `n` in `collapse(n)` should be no more than the number of actual perfectly nested do-loops, etc.. Original-commit: flang-compiler/f18@572a57d Reviewed-on: flang-compiler/f18#962
mem-frob
pushed a commit
to draperlaboratory/hope-llvm-project
that referenced
this pull request
Oct 7, 2022
…compiler/f18#962) This refers to three rules in OpenMP 4.5 Spec 2.15.1.1: * The loop iteration variable(s) in the associated do-loop(s) of a do, parallel do, taskloop, or distribute construct is (are) private. * The loop iteration variable in the associated do-loop of a simd construct with just one associated do-loop is linear with a linear-step that is the increment of the associated do-loop. * The loop iteration variables in the associated do-loops of a simd construct with multiple associated do-loops are lastprivate. A simple example: ``` implicit none integer :: N = 1024 integer i, j, k !$omp parallel do collapse(3) do i=1, N <- i is private do j=1, N <- j is private do k=1, N <- k is private enddo enddo enddo end ``` If `collapse` clause is not present, the associated do-loop for construct `parallel do` is only `i` loop. With `collapse(n)`, `i`, `j`, and `k` are all associated do-loops and the loop index variables are private to the OpenMP construct: ``` implicit none !DEF: /MainProgram1/n ObjectEntity INTEGER(4) integer :: n = 1024 !DEF: /MainProgram1/i ObjectEntity INTEGER(4) !DEF: /MainProgram1/j ObjectEntity INTEGER(4) !DEF: /MainProgram1/k ObjectEntity INTEGER(4) integer i, j, k !$omp parallel do collapse(3) !DEF: /MainProgram1/Block1/i (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do i=1,n !DEF: /MainProgram1/Block1/j (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do j=1,n !DEF: /MainProgram1/Block1/k (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do k=1,n end do end do end do end program ``` This implementation assumes that the structural checks for do-loops are done at this point, for example the `n` in `collapse(n)` should be no more than the number of actual perfectly nested do-loops, etc.. Original-commit: flang-compiler/f18@572a57d Reviewed-on: flang-compiler/f18#962
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This refers to three rules in OpenMP 4.5 Spec 2.15.1.1:
parallel do, taskloop, or distribute construct is (are) private.
construct with just one associated do-loop is linear with a linear-step
that is the increment of the associated do-loop.
construct with multiple associated do-loops are lastprivate.
A simple example:
If
collapseclause is not present, the associated do-loop for constructparallel dois onlyiloop. Withcollapse(n),i,j, andkareall associated do-loops and the loop index variables are private to the
OpenMP construct:
This implementation assumes that the structural checks for do-loops
are done at this point, for example the
nincollapse(n)shouldbe no more than the number of actual perfectly nested do-loops, etc..