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.
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
[flang][OpenMP] Try to unify induction var privatization for OMP regions. #91116
[flang][OpenMP] Try to unify induction var privatization for OMP regions. #91116
Changes from 25 commits
6ad9565
833b600
e29c7d4
1bf0e55
d74cb3e
fe35620
fd2d53f
81f4e77
cdb92c9
894a83e
dfade68
0d24b41
001c0fe
82d8ea0
b513a79
919309e
27ebcea
6985a27
f77c47f
696cde8
05c013f
2e067c4
3abb935
1023e05
0fe21cf
eb20e54
b4612b3
9c909d0
cbdb1e5
799c616
25b8b9d
33114ee
dcc1558
9bb2215
3e5c63c
6f1bcee
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
@kiranchandramohan @luporl just to clarify this change:
Since
omp ordered
does not have its own data-sharing environment, I think we should consider symbols referenced by anomp ordered
construct to be separate from the symbols referenced by the parent region.The changes here make sure that for the following input,
i
to be collected as of the symbols to be privatized for theomp do ordered
construct: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.
It is not clear to me why the ordered construct is a special case. Will the same issue be resolved by a fix similar to #90671 ?
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.
I can describe the problem in more detail but cannot claim my solution is the proper one.
For the above example program, this is the output of
flang-new -fc1 -fopenmp -fdebug-unparse-with-symbols
:So,
i
is marked as beingREF
ed from within theomp ordered
construct (not defined).However, when you call
converter.collectSymbolSet(nestedEval, symbolsInNestedRegions, ...)
whennestedEval
is theomp ordered
construct,i
will be one of the symbols collected in that nested region.This in turn, causes
i
not to be privatized when privatizing symbols that should be privatized for theomp do ordered
construct (i
is skipped because it is referenced by a nested region).Since,
omp ordered
does not have a data environment of its own (as far as I understand), I thought it would reasonable to not exclude the symbols collected for a nested eval when that nested eval is anordered
directive.That said, I am not sure this is the proper location for that kind of fix. But a similar fix to what was introduced in #90671 does not seem to work. Tried adding that in
bool OmpAttributeVisitor::Pre(const parser::OpenMPBlockConstruct &x);
but I get the same problem described above.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.
I think we can fix this separately. Could you check whether the same issue happens with the Critical construct?
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.
#90671 fixed symbol handling in semantics, which was enough to fix #78936, but not #75767.
Maybe the issue here is similar to #75767.
In any case, I agree that this can be fixed separately.
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.
Thanks both for the review.
That indeed causes the same issue. I will add a similar "fix" and a test before merging.
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.
I have a small question. I am not able to map how control-flow is coming to
collectSymbolsInNestedRegions
and other functionality, which is related to default clause. When I try a simple example as:I get semantic error as:
error: DEFAULT clause is not allowed on the DO directive
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.
I think this error happens earlier in semantics because
OMPC_Default
is not listed in the allowed clauses ofOMP_Do
in "llvm/include/llvm/Frontend/OpenMP/OMP.td". Not sure whether it should be allowed or not (making that error expected), since I'm not familiar with that part of the spec.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.
Thanks! Indeed it is from semantics. I was mainly checking if default privatization logic is being invoked uncharacteristically when it should not (i.e. when
default(...)
is not specified).I'm looking into this