-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[mlir][OpenMP][flang] make private variable allocation implicit in omp.private #124019
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
Merged
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
c955ae4
[mlir][OpenMP] Change the definition of omp.private
tblah 444e16f
Fix bug when used with lastprivate
tblah 4b3c1dc
Support char types
tblah 3385b3e
Fix omp target maps for privatized symbols
tblah 50c6e3a
Support pointers
tblah 15e59a7
Fix crash lowering fir::EmboxOp whithout shape
tblah f4c129a
Support derived types
tblah 0d8b42d
Implement lupori's derive type initialization patch
tblah eebf59c
Deallocate derived types
tblah 6953f3f
Support arrays of polymorphic types
tblah 81a6b26
Fix compiler crash for unnesecarry len params
tblah 61c0d3b
Readability improvments
tblah 729ae4c
Fix MLIR test
tblah 3d6141d
More readability improvments
tblah e67683e
Allow block arguments in MapsForPrivatizedSymbols
tblah 9c22293
Add negative tests for barriers
tblah 9284bb3
Fix test broken after rebase
tblah 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
Oops, something went wrong.
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.
Sorry @tblah for the late comment to this PR. I am looking into an issue that came up recently, and I believe it's related to this check here and your extensions to initialize that flag also during delayed privatization. So, I wanted to ask about it to try to understand it better, and see what the best solution is.
As far as I can tell, the
mightHaveReadHostSym
flag is set globally. That is, whenever a symbol is known to either initialize a clone or to have a privatizer with an init mold argument that is used, this will be true. Then, a barrier will be inserted e.g. if it is true and there are anylastprivate
symbols. Is that the intended behavior?My concern is that it doesn't look at whether the
lastprivate
symbol is the same one that caused the flag to be set. This is something that is triggered in the following example:The
i
variable is implicitly marked aslastprivate
(not sure where that's done, but I'm assuming it'ssimd
-specific behavior) and there is aprivate
clause for a non-primitive type, so this results in the insertion of a barrier. However, replacingsimd
fordo
no longer causes this issue becausei
is no longerlastprivate
then. I was just wondering if it's on purpose that we're adding a barrier due to different symbols meeting each side of the condition.I guess that would have been triggered previously as well, it's just that this change made it also happen for delayed privatization, which then impacts composite construct lowering and ends up triggering an MLIR verifier error for target SPMD due to the added barrier.
Maybe @ergawy or @luporl can also chime in if you know whether this is the expected behavior. I have a small patch updating
mightHaveReadHostSym
so that a barrier would not be inserted in this case, which I can share if this isn't expected behavior.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.
AFAIU, a barrier should not be needed in this case, since it is not possible to have concurrent read/write of the same memory region, as
i
is only written to in the last iteration and, as it seems,x
is only read during privatization (this could probably be optimized, sincex
's shape is known at compile time).I hadn't noticed it before, but having a single
mightHaveReadHostSym
variable for all privatized symbols is a problem indeed. A possible solution would be to have a per-symbolmightHaveReadHostSym
.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.
Thank you for the quick response. I just created #127074 to address the second part of the issue. Though it looks like, from what you're saying, we might want to treat induction variables differently as well?
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 for the quick fix.
I only wanted to point out that, in this case,
x
wouldn't even need to be read at all.Actually, this optimization is implemented in #125901.
Do you think there is any advantage in treating induction variables differently?
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.
Ah, thank you for the explanation, that makes sense. I would try to have as few edge cases as possible, so if we can get away with treating every variable the same way, I'd prefer it.
DO loop bounds have to be scalars, so it seems to me that the induction variable couldn't trigger this via the
mightHaveReadHostSym=true
path. Also, semantics triggers an error about passing a loop induction variable into afirstprivate
clause, so it seems like we should be fine without adding an edge case for this.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.
Sorry for my slow response @skatrak, I was on holiday. Thanks for fixing it, and thanks @luporl for chiming in.