-
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| ! Fixes a bug when a block variable is marked as implicit private. In such | ||
| ! case, 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: } | ||
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.