maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/flang/test/Semantics/omp-symbol02.f90

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

26 lines
759 B
Fortran
Raw Normal View History

[flang][NFC] Simplify semantics test scripts There were several different ways of handling the option to f18 to find predefined modules: - test_errors.sh was created by cmake substituting FLANG_INTRINSIC_MODULES_DIR into test_errors.sh.in - some tests used the flang script which has the option built it - some tests used %f18_with_includes which was replaced by the path to f18 plus the -I option - some included -I../../include/flang in their run command To make this more consistent, change %f18 to include the -intrinsic-module-directory option and use it everywhere, including to replace %flang and %f18_with_includes. This requires changing all of the invocations of the test scripts to put %f18 at the end so that it can expand to more than one argument. This eliminates the need to generate test_errors.sh which means we don't need flang/test/Semantics/CMakeLists.txt or the %B substitution. That makes the test_errors.sh command like the others, replacing %B/test/Semantics/test_errors.sh with %S/test_errors.sh. Also remove the OPTIONS: functionality as custom options can be included in the RUN: command. And remove -I/../../include/flang as that is now always included. Differential Revision: https://reviews.llvm.org/D79634
2020-05-12 02:38:53 +08:00
! RUN: %S/test_symbols.sh %s %t %f18 -fopenmp
[flang] [OpenMP] OmpVisitor framework for Name Resolution This is a preliminary framework to do the name resolution for data references on the OpenMP clauses. Unlike data references in the OpenMP region, clauses determining the data-sharing or data-mapping attributes are straightforward and the resolution process could be extended to do the name resolution in the OpenMP region. It is hard to determine what kind of checks can be done in this visitor and what checks should be done later after name resolution. But the guide line is that `After the completion of this phase, every Name corresponds to a Symbol with proper OpenMP attribute(s) determined unless an error occurred.` 1. Take data-sharing clauses as example, create new symbol for variable that require private access within the OpenMP region. Declare the entity implicitly if necessary. The new symbol has `HostAssocDetails`, which is mentioned in the `OpenMP-semantics.md`. 2. For `Shared` or `ThreadPrivate`, no symbol needs to be created. OpenMP attribute Flag `OmpThreadprivate` needs to be marked for `Threadprivate` because the `threadprivate` attribute remains the same whenever these variables are referenced in the program. `Names` in `Shared` clause need to be resolved to associate the symbols in the clause enclosing scope (contains the OpenMP directive) but `OmpShared` does not need to be marked. Declare the entity implicitly if necessary. 3. For `COMMON block`, when a named common block appears in a list, it has the same meaning as if every explicit member of the common block appeared in the list. Also, a common block name specified in a data-sharing attribute clause must be declared to be a common block in the same scoping unit in which the data-sharing attribute clause appears. So, if a named common block appears on a `PRIVATE` clause, all its members should have new symbols created within the OpenMP region (scope). For later Semantic checks and CG, a new symbol is also created for common block name with `HostAssocDetails`. There are many things are still on the TODO list: - Better error/warning messages with directive/clause source provenance - Resolve variables referenced in the OpenMP region, for example, `private(tt%a)` is not allowed but `tt%a = 1` is allowed in the OpenMP region and a private version of `tt` maybe created for the region. The functions created in the `OmpVisitor` should be able to handle the name resolution on the statement too (more data structures may be introduced). This is a big portion and may require some interface changes to distinguish a reference is on `OpenMP directive/clause` or `statements within OpenMP region`. - Same data reference appears on multiple data-sharing clauses. - Take association into consideration for example Pointer association, `ASSOCIATE` construct, and etc. - Handle `Array Sections` and `Array or Structure Element`. - Handle all the name resolution for directives/clauses that have `parser::Name`. - More tests Original-commit: flang-compiler/f18@b2ea520885eceb6e118f690b95e1846183fe378b
2019-09-12 05:42:51 +08:00
! 1.4.1 Structure of the OpenMP Memory Model
! Test implicit declaration in the OpenMP directive enclosing scope
! through clause; also test to avoid creating multiple symbols for
! the same variable
!DEF: /MainProgram1/b (Implicit) ObjectEntity REAL(4)
b = 2
!DEF: /MainProgram1/c (Implicit) ObjectEntity REAL(4)
c = 0
[flang] [OpenMP] Implement no-multiple-appearance rule for DSA Clauses DSA stands for Data-Sharing Attribute. This work is part of the Name Resolution for OpenMP framework (data-refs on clauses part) Based on 2.15.3: A list item that specifies a given variable may not appear in more than one clause on the same directive, except that a variable may be specified in both firstprivate and lastprivate clauses. Through a temporary `std::set` of `const Symbol *` to keep track of all the symbols on a certain OpenMP directive, we can determine whether a variable `Name` (or `Symbol`, more accurately) has already appeared on another DSA clause already, with the exception of FIRSTPRIVATE clause and LASTPRIVATE clause. This rule applies to `/COMMON block/` also and the source provenance shows on error message points to the `Name` between slashes. Added two more tests and changed some existing tests to accommodate this commit. I intend to keep the `omp-clause-validity01.f90` test to do the validity checks only. Original-commit: flang-compiler/f18@0d7828c21e8dfe02e470a861178b7747100516ae
2019-09-18 08:52:46 +08:00
!$omp parallel private(a,b) shared(c,d)
[flang] [OpenMP] OmpVisitor framework for Name Resolution This is a preliminary framework to do the name resolution for data references on the OpenMP clauses. Unlike data references in the OpenMP region, clauses determining the data-sharing or data-mapping attributes are straightforward and the resolution process could be extended to do the name resolution in the OpenMP region. It is hard to determine what kind of checks can be done in this visitor and what checks should be done later after name resolution. But the guide line is that `After the completion of this phase, every Name corresponds to a Symbol with proper OpenMP attribute(s) determined unless an error occurred.` 1. Take data-sharing clauses as example, create new symbol for variable that require private access within the OpenMP region. Declare the entity implicitly if necessary. The new symbol has `HostAssocDetails`, which is mentioned in the `OpenMP-semantics.md`. 2. For `Shared` or `ThreadPrivate`, no symbol needs to be created. OpenMP attribute Flag `OmpThreadprivate` needs to be marked for `Threadprivate` because the `threadprivate` attribute remains the same whenever these variables are referenced in the program. `Names` in `Shared` clause need to be resolved to associate the symbols in the clause enclosing scope (contains the OpenMP directive) but `OmpShared` does not need to be marked. Declare the entity implicitly if necessary. 3. For `COMMON block`, when a named common block appears in a list, it has the same meaning as if every explicit member of the common block appeared in the list. Also, a common block name specified in a data-sharing attribute clause must be declared to be a common block in the same scoping unit in which the data-sharing attribute clause appears. So, if a named common block appears on a `PRIVATE` clause, all its members should have new symbols created within the OpenMP region (scope). For later Semantic checks and CG, a new symbol is also created for common block name with `HostAssocDetails`. There are many things are still on the TODO list: - Better error/warning messages with directive/clause source provenance - Resolve variables referenced in the OpenMP region, for example, `private(tt%a)` is not allowed but `tt%a = 1` is allowed in the OpenMP region and a private version of `tt` maybe created for the region. The functions created in the `OmpVisitor` should be able to handle the name resolution on the statement too (more data structures may be introduced). This is a big portion and may require some interface changes to distinguish a reference is on `OpenMP directive/clause` or `statements within OpenMP region`. - Same data reference appears on multiple data-sharing clauses. - Take association into consideration for example Pointer association, `ASSOCIATE` construct, and etc. - Handle `Array Sections` and `Array or Structure Element`. - Handle all the name resolution for directives/clauses that have `parser::Name`. - More tests Original-commit: flang-compiler/f18@b2ea520885eceb6e118f690b95e1846183fe378b
2019-09-12 05:42:51 +08:00
!DEF: /MainProgram1/Block1/a (OmpPrivate) HostAssoc REAL(4)
a = 3.
!DEF: /MainProgram1/Block1/b (OmpPrivate) HostAssoc REAL(4)
b = 4
!REF: /MainProgram1/c
c = 5
!DEF: /MainProgram1/d (Implicit) ObjectEntity REAL(4)
d = 6
!$omp end parallel
!DEF: /MainProgram1/a (Implicit) ObjectEntity REAL(4)
print *, a
end program