-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[flang][OpenMP] Explicitly set Shared DSA in symbols #142154
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
Conversation
@llvm/pr-subscribers-flang-semantics @llvm/pr-subscribers-flang-fir-hlfir Author: Leandro Lupori (luporl) ChangesBefore this change, OmpShared was not always set in shared symbols. Because of the host association symbols with no flags mentioned Besides that, some semantic checks need to know if a DSA clause With the changes above, AddToContextObjectWithDSA() and the symbol Some debug messages were also added, with the "omp" DEBUG_TYPE, to Fixes #130533 Patch is 55.90 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/142154.diff 26 Files Affected:
|
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.
LGTM, the approach seems sensible and it is okay with me. Do you plan to follow up with the lowering changes required to clean this up?
Yes, but it may take a while. |
Before this change, OmpShared was not always set in shared symbols. Instead, absence of private flags was interpreted as shared DSA. The problem was that symbols with no flags, with only a host association, could also mean "has same DSA as in the enclosing context". Now shared symbols behave the same as private and can be treated the same way. Because of the host association symbols with no flags mentioned above, it was also incorrect to simply test the flags of a given symbol to find out if it was private or shared. The function GetSymbolDSA() was added to fix this. It would be better to avoid the need of these special symbols, but this would require changes to how symbols are collected in lowering. Besides that, some semantic checks need to know if a DSA clause was used or not. To avoid confusing implicit symbols with DSA clauses a new flag was added: OmpExplicit. It is now set for all symbols with explicitly determined data-sharing attributes. With the changes above, AddToContextObjectWithDSA() and the symbol to DSA map could probably be removed and the DSA could be obtained directly from the symbol, but this was not attempted. Some debug messages were also added, with the "omp" DEBUG_TYPE, to make it easier to debug the creation of implicit symbols and to visualize all associations of a given symbol. Fixes llvm#130533 Fixes llvm#140882
6c89ac2
to
cf64aac
Compare
Before this change, OmpShared was not always set in shared symbols. Instead, absence of private flags was interpreted as shared DSA. The problem was that symbols with no flags, with only a host association, could also mean "has same DSA as in the enclosing context". Now shared symbols behave the same as private and can be treated the same way. Because of the host association symbols with no flags mentioned above, it was also incorrect to simply test the flags of a given symbol to find out if it was private or shared. The function GetSymbolDSA() was added to fix this. It would be better to avoid the need of these special symbols, but this would require changes to how symbols are collected in lowering. Besides that, some semantic checks need to know if a DSA clause was used or not. To avoid confusing implicit symbols with DSA clauses a new flag was added: OmpExplicit. It is now set for all symbols with explicitly determined data-sharing attributes. With the changes above, AddToContextObjectWithDSA() and the symbol to DSA map could probably be removed and the DSA could be obtained directly from the symbol, but this was not attempted. Some debug messages were also added, with the "omp" DEBUG_TYPE, to make it easier to debug the creation of implicit symbols and to visualize all associations of a given symbol. Fixes llvm#130533 Fixes llvm#140882
Before this change, OmpShared was not always set in shared symbols. Instead, absence of private flags was interpreted as shared DSA. The problem was that symbols with no flags, with only a host association, could also mean "has same DSA as in the enclosing context". Now shared symbols behave the same as private and can be treated the same way. Because of the host association symbols with no flags mentioned above, it was also incorrect to simply test the flags of a given symbol to find out if it was private or shared. The function GetSymbolDSA() was added to fix this. It would be better to avoid the need of these special symbols, but this would require changes to how symbols are collected in lowering. Besides that, some semantic checks need to know if a DSA clause was used or not. To avoid confusing implicit symbols with DSA clauses a new flag was added: OmpExplicit. It is now set for all symbols with explicitly determined data-sharing attributes. With the changes above, AddToContextObjectWithDSA() and the symbol to DSA map could probably be removed and the DSA could be obtained directly from the symbol, but this was not attempted. Some debug messages were also added, with the "omp" DEBUG_TYPE, to make it easier to debug the creation of implicit symbols and to visualize all associations of a given symbol. Fixes llvm#130533 Fixes llvm#140882
Although taskgroup is a privatizing construct, because of task_reduction clause, a new scope was not being created for it. This could cause an extra privatization of variables when taskgroup was lowered, because its scope would be the same as of the parent privatizing construct. This fixes regressions in tests 1052_0201 and 1052_0205, from Fujitsu testsuite. This issue didn't happen before because implicit symbols were being created in a different way before llvm#142154.
Although taskgroup is a privatizing construct, because of task_reduction clause, a new scope was not being created for it. This could cause an extra privatization of variables when taskgroup was lowered, because its scope would be the same as of the parent privatizing construct. This fixes regressions in tests 1052_0201 and 1052_0205, from Fujitsu testsuite. This issue didn't happen before because implicit symbols were being created in a different way before #142154.
Although taskgroup is a privatizing construct, because of task_reduction clause, a new scope was not being created for it. This could cause an extra privatization of variables when taskgroup was lowered, because its scope would be the same as of the parent privatizing construct. This fixes regressions in tests 1052_0201 and 1052_0205, from Fujitsu testsuite. This issue didn't happen before because implicit symbols were being created in a different way before llvm#142154.
Although taskgroup is a privatizing construct, because of task_reduction clause, a new scope was not being created for it. This could cause an extra privatization of variables when taskgroup was lowered, because its scope would be the same as of the parent privatizing construct. This fixes regressions in tests 1052_0201 and 1052_0205, from Fujitsu testsuite. This issue didn't happen before because implicit symbols were being created in a different way before llvm#142154.
Before this change, OmpShared was not always set in shared symbols.
Instead, absence of private flags was interpreted as shared DSA.
The problem was that symbols with no flags, with only a host
association, could also mean "has same DSA as in the enclosing
context". Now shared symbols behave the same as private and can be
treated the same way.
Because of the host association symbols with no flags mentioned
above, it was also incorrect to simply test the flags of a given
symbol to find out if it was private or shared. The function
GetSymbolDSA() was added to fix this. It would be better to avoid
the need of these special symbols, but this would require changes
to how symbols are collected in lowering.
Besides that, some semantic checks need to know if a DSA clause
was used or not. To avoid confusing implicit symbols with DSA
clauses a new flag was added: OmpExplicit. It is now set for all
symbols with explicitly determined data-sharing attributes.
With the changes above, AddToContextObjectWithDSA() and the symbol
to DSA map could probably be removed and the DSA could be obtained
directly from the symbol, but this was not attempted.
Some debug messages were also added, with the "omp" DEBUG_TYPE, to
make it easier to debug the creation of implicit symbols and to
visualize all associations of a given symbol.
Fixes #130533
Fixes #140882