This is an archive of the discontinued LLVM Phabricator instance.

[flang][OpenMP] Add some semantic checks for threadprivate and declare target directives
ClosedPublic

Authored by peixin on Dec 2 2021, 3:24 AM.

Details

Summary

This supports the following checks for THREADPRIVATE Directive:

[5.1] 2.21.2 THREADPRIVATE Directive
A threadprivate variable must not appear in any clause except the 
copyin, copyprivate, schedule, num_threads, thread_limit, and if clauses.

This supports the following checks for DECLARE TARGET Directive:

[5.1] 2.14.7 Declare Target Directive
A threadprivate variable cannot appear in the directive.

Besides, procedure name and the entity with PARAMETER attribute cannot
be in the threadprivate directive. The main program name and module name
cannot be in the threadprivate directive and declare target directive.
There is no clear description or restriction about the entity with
PARAMETER attribute in OpenMP 5.1 Specification, and a warning is given.

Diff Detail

Event Timeline

peixin created this revision.Dec 2 2021, 3:24 AM
peixin requested review of this revision.Dec 2 2021, 3:24 AM
peixin added a comment.Dec 2 2021, 3:25 AM

Most of semantic checks for threadprivate directive should be done after this patch.

Hi @peixin . Thanks for this patch. I have a few comments and questions for the declare target checks. I will review the threadprivate checks soon.

flang/lib/Semantics/check-omp-structure.cpp
864

I cannot find a test for this error. Can we add that?

872

Same. No tests for this.

flang/test/Semantics/omp-declarative-directive.f90
47–48

I am trying to understand the why is there a warning here. Example declare_target.3.f90 on Page 183 in the OpenMP 5.0 Examples Document allows the usage of #declare target (N). Can it be removed?

flang/test/Semantics/omp-declare-target02.f90
65–66

This should not be the error, right? As this is accepted by the OpenMP Standard. (Are we planning to remove this later?)

68–69

Why is this an error? The declaration of the common block is in the same scope. Can we have a correct behavior test for this? (when the common block is accepted without errors)

76–77

This and other similar variables like blk2_link, bl3_to etc. are not declared variables. As far as I understand, they all really represent the same case. Can the others be removed and the one case be given a random name to avoid confusion? (Let me know if I have missed something here as I am not a Fortran expert)

flang/test/Semantics/omp-declare-target03.f90
14

GFortran does not report this error. The standard says "The directive must appear in the declaration section of a scoping unit in which the common block or variable is declared.". I believe it means that the constraint is that variable should not be out-of-scope and it is not necessary that the declaration is on the same level.

peixin updated this revision to Diff 391971.Dec 5 2021, 10:48 PM
peixin edited the summary of this revision. (Show Details)

Thanks @shraiysh for the review. Made changes according to the comments.

flang/lib/Semantics/check-omp-structure.cpp
864

Add the test case in omp-threadprivate03.f90.

872

Add the test case in omp-threadprivate03.f90.

flang/test/Semantics/omp-declarative-directive.f90
47–48

The example is truly there. As described in summary, the problem is that there is no clear description or restriction about the entity with PARAMETER attribute in OpenMP 5.1 Specification. I asked help for @Meinersbur that we asked about this issue in the openmp committee. There may be detailed discussion about the entity with PARAMETER attribute in declare target construct in OpenMP 6.0.

flang/test/Semantics/omp-declare-target02.f90
65–66

"blk2" is not "/blk2/". The common block must be specified with "/ /" in threadrpviate and declare target directives. "blk2" is undeclared variable here. Since this patch does not provide new semantic errors about undeclared variable, this test case is removed. The error of "Implicitly typed local entity 'blk2' not allowed in specification expression" was wrong, which should be fixed in another patch later.

68–69

Same as above.

76–77

Removed all the test cases of undeclared variables.

flang/test/Semantics/omp-declare-target03.f90
14

I think you are right. I do not think out one reason to not use the directive and variable in different scoping units.

The patch functionally LGTM, but I have not worked on these files and would suggest you to wait for someone else's review (someone who has worked on semantic checks for flang) before merging this.

Minor comments.

flang/lib/Semantics/check-omp-structure.cpp
876

There is no test for this. Is this supposed to be an error? (I see that you have not used _err_en_US here, so why is this message here?)

1479–1480

This same error is reported above too. Can you please explain why there is a duplication of code and if possible, can we merge the objects on which this has loop has to run (mem and name) and run this loop only once?

flang/test/Semantics/omp-declare-target02.f90
65–66

Okay, I cannot find a test case for declare target with proper usage of blocks. Can you please add that if it is not already there?

Thanks for the patch @peixin. The semantic checks LGTM

peixin added a comment.Dec 8 2021, 5:04 PM

Thanks @shraiysh and @NimishMishra for the review. I will wait for more reviews.

flang/lib/Semantics/check-omp-structure.cpp
876

With _en_US, it emits one warning, which is usually generated for unspecified behaviors. Please check omp-declarative-directive.f90 (two warnings for variables "N" and "M".

1479–1480

This is not duplication. The std::visit walks along the parse-tree from "ompObject.u". The "parse::Name" is for common block, and "parser::Designator" is for scalar, array, and so on. This is defined in parse-tree. You can write one simple correct example, and dump the parse-tree with the option "-fdebug-dump-parse-tree" to check it.

flang/test/Semantics/omp-declare-target02.f90
65–66

Oh, you are right. The correct example is missed in my last patch. I will add it later.

Thanks for the explanation!

peixin updated this revision to Diff 395058.Dec 16 2021, 11:54 PM

Rebase and add the proper test case as @shraiysh mentioned.

peixin updated this revision to Diff 395252.Dec 17 2021, 6:50 PM

Remove the test case of using common block in declare target directive since resolving declare target directive has not been finished yet. This can be supported later.

@kiranchandramohan Can I land this patch considering it looks ok to @NimishMishra and @shraiysh ?

shraiysh accepted this revision.Dec 30 2021, 7:21 PM

@peixin I think we can merge this to make progress and if Kiran has any post-commit comments, we can address them later.

This revision is now accepted and ready to land.Dec 30 2021, 7:21 PM
peixin added a comment.Jan 1 2022, 7:30 AM

@shraiysh Thanks for accepting this patch. This path is the last one of semantic checks for threadprivate directive and won't block others. Most people are still on vacation. I can wait for a few more days to see if there will be more comments.

kiranchandramohan accepted this revision.Jan 4 2022, 5:36 AM

LGTM.

@peixin I think we can merge this to make progress and if Kiran has any post-commit comments, we can address them later.

+1

flang/lib/Semantics/check-omp-structure.cpp
1479–1480

One trivial code-sharing will be to have a lambda that, given a symbol, tests the Threadprivate flag and prints the error.

peixin updated this revision to Diff 397477.Jan 5 2022, 1:39 AM

Use lambda to reduce the code redundancy.

peixin added a comment.Jan 5 2022, 1:41 AM

Thanks for @kiranchandramohan accepting this patch. Addressed the comment.

flang/lib/Semantics/check-omp-structure.cpp
1479–1480

Good idea. Fixed.