-
Notifications
You must be signed in to change notification settings - Fork 15.5k
[flang][OpenMP] Don't privatize implicit symbols declare by nested BLOCKs
#152973
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
ergawy
merged 2 commits into
main
from
users/ergawy/do_not_privaize_nested_declarations_2
Aug 12, 2025
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| ! When a block variable is marked as implicit private, we can simply ignore | ||
| ! privatizing that symbol within the context of the currrent OpenMP construct | ||
| ! since the "private" allocation for the symbol will be emitted within the nested | ||
| ! block anyway. | ||
|
|
||
| ! RUN: %flang_fc1 -emit-hlfir -fopenmp %s -o - | FileCheck %s | ||
|
|
||
| subroutine block_implicit_privatization | ||
| implicit none | ||
| integer :: i | ||
|
|
||
| !$omp task | ||
| do i=1,10 | ||
| block | ||
| integer :: j | ||
| j = 0 | ||
| end block | ||
| end do | ||
| !$omp end task | ||
| end subroutine | ||
|
|
||
| ! CHECK-LABEL: func.func @_QPblock_implicit_privatization() { | ||
| ! CHECK: %[[I_DECL:.*]]:2 = hlfir.declare %{{.*}} {uniq_name = "{{.*}}Ei"} | ||
| ! CHECK: omp.task private(@{{.*}}Ei_private_i32 %[[I_DECL]]#0 -> %{{.*}} : !fir.ref<i32>) { | ||
| ! CHECK: fir.do_loop {{.*}} { | ||
| ! Verify that `j` is allocated whithin the same scope of its block (i.e. inside | ||
| ! the `task` loop). | ||
| ! CHECK: fir.alloca i32 {bindc_name = "j", {{.*}}} | ||
| ! CHECK: } | ||
| ! CHECK: } | ||
| ! 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.
Maybe it's because I'm not very familiar with this logic, but wouldn't the
visitor.isSymbolDefineBy(sym, eval)check need to be preserved? E.g.:visitor.isSymbolDefineBy(sym, eval) && !visitor.isSymbolDefineByNestedDeclaration(sym) && sym->test(semantics::Symbol::Flag::OmpPreDetermined).Uh oh!
There was an error while loading. Please reload this page.
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.
The symbol and its defining construct are added only once to
symDefMap. So, if we have ablockand within thatblockaDeclarationConstruct, the symbol will be paired with theDeclarationConstruct. If the symbol is later referenced by theevalfor which we are doing the privatization,symDefMapwill not be updated again.So the map track the first time we encounter a symbol and the context/construct where we did so.
Therefore, I think,
isSymbolDefineByNestedDeclarationis both more accurate and sufficient as a check.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.
@skatrak you were right, the check should be maintained. Removing it triggered a regression in Fujitsu. OpenMP newbie here 🤦!
I am working on a PR with a lit test.
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.
Opened #154070.