[PATCH] D93205: [Flang][OpenMP 4.5] Add semantic check for OpenMP Do Loop Constructs for single directive
Yashaswini Hegde via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 12 09:32:31 PST 2021
yhegde added inline comments.
================
Comment at: flang/lib/Semantics/check-omp-structure.cpp:153
+ case llvm::omp::OMPD_single:
+ for (const auto &dirContext : dirContext_) {
+ if (dirContext.directive == llvm::omp::Directive::OMPD_do) {
----------------
kiranchandramohan wrote:
> yhegde wrote:
> > kiranchandramohan wrote:
> > > yhegde wrote:
> > > > kiranchandramohan wrote:
> > > > > yhegde wrote:
> > > > > > kiranchandramohan wrote:
> > > > > > > yhegde wrote:
> > > > > > > > kiranchandramohan wrote:
> > > > > > > > > yhegde wrote:
> > > > > > > > > > kiranchandramohan wrote:
> > > > > > > > > > > yhegde wrote:
> > > > > > > > > > > > clementval wrote:
> > > > > > > > > > > > > `dirContext_` act as a stack so do you really intent to go from the bottom of the stack to the top? If so no problem. Just asking.
> > > > > > > > > > > > Yes. Check on nesting is called only if Do directive present in that stack.
> > > > > > > > > > > Should this call to HasInvalidWorksharingNesting be similar to the one in OpenMPLoopDirective and happen before pushing the context and not iterate over the entire stack of contexts?
> > > > > > > > > > In OpenMPLoopDirective OMPD_Do context is pushed after calling HasInvalidWorksharingNesting. So I could not do this check in a similar way.
> > > > > > > > > Is there any issue with pushing the context after calling HasInvalidWorksharingNesting here also?
> > > > > > > > I suppose you mean pushing OMPD_Do context after calling HasInvalidWorksharingNesting ? . If so , then it is not required to push that context later. Control reaches OpenMPLoopDirective first and then OMPD_single.
> > > > > > > I was asking whether it is OK to implement it the following way so that we don't have to use FindInEnclosingDirContext function?
> > > > > > >
> > > > > > > ```
> > > > > > > if (beginDir.v == llvm::omp::Directive::OMPD_single) {
> > > > > > > HasInvalidWorksharingNesting(...);
> > > > > > > }
> > > > > > >
> > > > > > > PushContextAndClauseSets(beginDir.source, beginDir.v);
> > > > > > >
> > > > > > > switch (beginDir.v) {
> > > > > > > case llvm::omp::OMPD_parallel:
> > > > > > > CheckNoBranching(block, llvm::omp::OMPD_parallel, beginDir.source);
> > > > > > > break;
> > > > > > > default:
> > > > > > > break;
> > > > > > > }
> > > > > > > }
> > > > > > > ```
> > > > > > FindEnclosingDirContext function can check any restrictive directives for "single" , like "critical" or "task" - if in case it is required to check . Otherwise I can call
> > > > > >
> > > > > > if (beginDir.v == llvm::omp::Directive::OMPD_single) {
> > > > > > HasInvalidWorksharingNesting(HasInvalidWorksharingNesting(
> > > > > > beginDir.source, {llvm::omp::Directive::OMPD_do}););
> > > > > > }
> > > > > >
> > > > > > before pushing the PushContextAndClauseSets(beginDir.source, beginDir.v) and get the expected error.
> > > > > >
> > > > > If you want to check for restrictions besides OMPD_do, then you can add them to the set like the following isn't it?
> > > > > ```
> > > > > if (beginDir.v == llvm::omp::Directive::OMPD_single) {
> > > > > HasInvalidWorksharingNesting(
> > > > > beginDir.source{llvm::omp::Directive::OMPD_do,
> > > > > llvm::omp::Directive::OMPD_critical,
> > > > > llvm::omp::Directive::OMPD_task});
> > > > > }
> > > > > ```
> > > > >
> > > > > Anyway the FindEnclosingDirContext is probably not needed for this patch. If we need it later then we can introduce it there. If you agree please remove FindEnclosingDirContext.
> > > > ok. Then I suppose 'single' binds to immediate outer directive context irrespective of that context. I have moved code before pushing the context. Thanks for the review comments.
> > > Can you point me to this restriction for single in the standard?
> > I was under an impression that FindInEnclosingDircontext check is required in one such following case:
> >
> > program omp_do
> > integer a(10),b(10),c(10)
> > !$omp parallel sections
> > !$omp section
> > !$omp critical
> > !$omp do
> > do i=1,10
> > !$omp parallel
> > a(i) = b(i) + c(i)
> > !$omp single
> > j = j + 1
> > !$omp end single
> > !$omp end parallel
> > end do
> > !$omp end critical
> > !$omp end parallel sections
> >
> > But may be it is enough to check immediate outer dir context. So I have updated the diff with suggested changes.
> To confirm whether it is a closely nested (construct/region) check or a general nested check, I would like to see which specific restriction you are implementing here from the standard. I could not find the single restriction in the worksharing loop section (2.7.1). Did I miss?
>
> However, I see the following in Section 2.17
> • A worksharing region may not be closely nested inside a worksharing, explicit task, taskloop, critical, ordered, atomic, or master region
>
> Please clarify which specific restriction you are implementing here.
The case related to 'single' - (omp-do05.f90) is listed under 2.7.1 with restriction description "All loops associated with the loop construct must be perfectly nested; that is, there must be no intervening code nor any OpenMP directive between any two loops.".
The spec https://www.openmp.org/wp-content/uploads/openmp-examples-4.5.0.pdf , page 277 , gives a similar example calling it as "non-conforming example because the loop and single regions are closely nested.
gfortran throws an error - "work-sharing region may not be closely nested inside of work-sharing, ‘critical’, ‘ordered’, ‘master’, explicit ‘task’ or ‘taskloop’ region" - for these cases.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D93205/new/
https://reviews.llvm.org/D93205
More information about the llvm-commits
mailing list