RFC: FIR Merge - PR1: Add ASTBuilder structure to help lowering the parse-tree #5
Conversation
This file contains 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 is an extended framework based on the previous work that addresses the NR on OpenMP directives/clauses (b2ea520). In this change: * New `OmpVisitor` is created (ResolveNamesVisitor derives from it) to create necessary scopes for certain OpenMP constructs. This is along with the regular Fortran NR process. * Old `OmpVisitor` is adjusted and converted to a standalone visitor-- `OmpAttributeVisitor`. This is used to walk through the OpenMP constructs and do the NR for variables on the OpenMP directives or data references within the OpenMP constructs. "Do the NR" here means that based on the NR results of the regular Fortran NR, fix the symbols of `Names` related to the OpenMP constructs. Note that there is an `OmpContext` in this visitor (similar to the one in `OmpStructureChecker`), this is necessary when dealing with the nested OpenMP constructs in the future. Given an OpenMP code: ``` real*8 a, b a = 1. b = 2. !$omp parallel private(a) a = 3. b = 4. !$omp end parallel print *, a, b end ``` w/o -fopenmp: ``` real*8 a, b !REF: /MainProgram1/a a = 1. !REF: /MainProgram1/b b = 2. !!!! OMP parallel !REF: /MainProgram1/a a = 3. !REF: /MainProgram1/b b = 4. !!!! OMP end parallel !REF: /MainProgram1/a !REF: /MainProgram1/b print *, a, b end ``` w/ -fopenmp: ``` real*8 a, b !REF: /MainProgram1/a a = 1. !REF: /MainProgram1/b b = 2. !$omp parallel private(a) <-- new Symbol for 'a' created !DEF: /MainProgram1/Block1/a (OmpPrivate) HostAssoc REAL(8) a = 3. <-- fix the old symbol with new Symbol in parallel scope !REF: /MainProgram1/b b = 4. <-- do nothing because by default it is shared in this scope !$omp end parallel !REF: /MainProgram1/a !REF: /MainProgram1/b print *, a, b end ``` Please note that this is a framework update, there are still many things on the TODO list for finishing the NR for OpenMP (based on the `OpenMP-semantics.md` design doc), which will be on top of this framework. Some TODO items: - Create a generic function to go through all the rules for deciding `predetermined`, `explicitly determined`, and `implicitly determined` data-sharing attributes. (This is the next biggest part) - Handle `Array Sections` and `Array or Structure Element`. - Take association into consideration for example Pointer association, `ASSOCIATE` construct, and etc. - Handle all the name resolution for directives/clauses that have `parser::Name`. * N.B. Extend `AddSourceRange` to apply to current and parent scopes - motivated by a few cases that need to call `AddSourceRange` for current & parent scopes; the extension should be safe - global scope is not included
…efault Remove `default` case for OmpSectionsDirective (only two enum values)
You cannot call an IMPURE procedure in a DO CONCURRENT construct. One way that can happen is if an entity with an IMPURE FINAL procedure gets deallocated. Similar to the checks for deallocating coarrays, there are three ways that an entity can get deallocated that are applicable to DO CONCURRENT constructs -- an actual DEALLOCATE statement, block exit, and assignment. This change depends on the utility function `HasImpureFinal()` in tools.h to determine if an entity has a derived type with an IMPURE FINAL procedure. In the course of testing this change, I realized that this check is incorrect, but the code specific to DO CONCURRENT is independent of the check, so I might as well implement it.
…inal Semantic checks for deallocating entities with IMPURE FINAL procedures
The test still wasn't correct for structure components. If the last part-ref is a non-array or a single array element, but the whole ArrayRef has non-zero rank, it is not contiguous. Otherwise, if there are subscripts on the last part-ref they can be checked normally. Add some tests for cases that were previously failing, and also for cases with vector subscripts.
Fix another bug checking simple contiguity
This is the story of implementing semantic checks for passing DO variables to functions with dummy arguments with INTENT(OUT) or INTENT(INOUT).
Explanation of how to implement a semantic check
While working on PR 959, I instanciated a `common::TupleToVariant` with ~50+ types inside the tuple. Clang would then crash after 1hr compilation with message: "constexpr evaluation hit maximum step limit; possible infinite loop" After investigating, it turned out clang handles very badly the way `common::AreTypesDistinctHelper` was implemented. Its "number of steps" was exponential with the number of types. This fix makes this number quadratic which solves the issue.
Address review comments Integer output data editing (I,B,O,Z) Full integer output formatting Stub out some work in progress Progress on E output data editing E, D, EN, and ES output editing done Fw.d output editing Real G output editing G output editing for reals Make environment a distinct module CHARACTER and LOGICAL output editing Minimal decimal representations for E0, F0, G0 editing Move real output editing code into its own file Fix/dodge some GCC build problems Prep work for external I/O statement state External HELLO, WORLD Fix build problem with GCC Add virtual destructors where needed Add new test
Formatted output editing & initial buffer framing code
…ng-template-step-limit Fix template step limit issue with clang
…#962) This refers to three rules in OpenMP 4.5 Spec 2.15.1.1: * The loop iteration variable(s) in the associated do-loop(s) of a do, parallel do, taskloop, or distribute construct is (are) private. * The loop iteration variable in the associated do-loop of a simd construct with just one associated do-loop is linear with a linear-step that is the increment of the associated do-loop. * The loop iteration variables in the associated do-loops of a simd construct with multiple associated do-loops are lastprivate. A simple example: ``` implicit none integer :: N = 1024 integer i, j, k !$omp parallel do collapse(3) do i=1, N <- i is private do j=1, N <- j is private do k=1, N <- k is private enddo enddo enddo end ``` If `collapse` clause is not present, the associated do-loop for construct `parallel do` is only `i` loop. With `collapse(n)`, `i`, `j`, and `k` are all associated do-loops and the loop index variables are private to the OpenMP construct: ``` implicit none !DEF: /MainProgram1/n ObjectEntity INTEGER(4) integer :: n = 1024 !DEF: /MainProgram1/i ObjectEntity INTEGER(4) !DEF: /MainProgram1/j ObjectEntity INTEGER(4) !DEF: /MainProgram1/k ObjectEntity INTEGER(4) integer i, j, k !$omp parallel do collapse(3) !DEF: /MainProgram1/Block1/i (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do i=1,n !DEF: /MainProgram1/Block1/j (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do j=1,n !DEF: /MainProgram1/Block1/k (OmpPrivate) HostAssoc INTEGER(4) !REF: /MainProgram1/n do k=1,n end do end do end do end program ``` This implementation assumes that the structural checks for do-loops are done at this point, for example the `n` in `collapse(n)` should be no more than the number of actual perfectly nested do-loops, etc..
C702 (R701) A colon shall not be used as a type-param-value except in the declaration of an entity that has the POINTER or ALLOCATABLE attribute. I added code to the visitor for a TypeDeclarationStmt to check for the 'LEN' type parameter for strings and to loop over the type parameters for derived types. I also ran into a few situations where previous tests had erroneously used a colon for type parameters without either the POINTER or ALLOCATABLE attribute and fixed them up.
Semantic checks for C702
- Remove SubprogramDetails copy ctor - Prevent copies in range based loops over symbols - Remove unsued var
…0-warnings Fix issues comming from clang-10 warnings
The call to `std::min` failed to compile with GCC on macOS due to type inference because `std::size_t` is `long unsigned int` but `std::int64_t` is `long long int`.
Fix compilation error on macOS
Updated the description of `evaluate::Expr` types
I implemented and added tests for constraints C703, C704, C705, C706, and C796. In some cases, the code and/or test already existed, and all I did was add a notation indicating the associated constraint.
Semantic checks for constraints on types
Use internal units for internal I/O state Replace use of virtual functions reference_wrapper Internal formatted output to array descriptor Delete dead code Begin list-directed internal output Refactorings and renamings for clarity List-directed external I/O (character) COMPLEX list-directed output Control list items First cut at unformatted I/O More OPEN statement work; rename class to ExternalFileUnit Complete OPEN (exc. for POSITION=), add CLOSE() OPEN(POSITION=) Flush buffers on crash and for terminal output; clean up Documentation Fix backquote in documentation Fix typo in comment Begin implementation of input Refactor binary floating-point properties to a new header, simplify numeric output editing Dodge spurious GCC 7.2 build warning Address review comments
Progress on Fortran I/O runtime
An entity declared with the CLASS keyword shall be a dummy argument or have the ALLOCATABLE or POINTER attribute. Implementing this check revealed a problem in the test resolve44.cpp. It also showed that we were doing semantic checking on the entities created by the compiler for LOCAL and LOCAL_INIT locality-specs. So I changed the creation of symbols associated with LOCAL and LOCAL_INIT locality-specs to be host associated with the outer symbol rather than new object entities. In the process, I also changed things so that the `parser::Name` associated with the newly created symbols was set to the symbol rather than being set to nullptr.
Semantic check for C708
Note: This commit does not reflect an actual work log, it is a feature based split of the changes done in the FIR experimental branch. The related work log can be found in the commits between: schweitzpgi@8c320e3 and: schweitzpgi@9b9ea05
The Pre-FIR Tree structure is a transient data structure that is meant to be built from the parse tree just before lowering to FIR and that will be deleted just afterwards. It is not meant to perfrom optimization analysis and transformations. It only provides temporary information, such as label target information or parse tree parent nodes, that is meant to be used to lower the parse tree structure into FIR operations. A PFTBuilder class builds the Pre-Fir Tree from the parse-tree. A pretty printer is available to visualize this data structure. - Lit tests are added to: 1. that the PFT tree structure is as expected 2. that the PFT captures all intented nodes - Cmake changes: Prevent warnings inisde LLVM headers when compiling flang The issue is that some LLVM headers define functions where the usage of the parameters depend on environment ifdef. See for instance Size in: https://github.com/llvm/llvm-project/blob/5f940220bf9438e95ffa4a627ac1591be1e1ba6e/llvm/include/llvm/Support/Compiler.h#L574 Because flang is build with -Werror and -Wunused-parameter is default in clang, this may breaks build in some environments (like with clang9 on macos). A solution would be to add -Wno-unused-parameter to flang CmakLists.txt, but it is wished to keep this warning on flang sources for quality purposes. Fixing LLVM headers is not an easy task and `[[maybe_unused]]` is C++17 and cannot be used yet in LLVM headers. Hence, this fix simply silence warnings coming from LLVM headers by telling CMake they are to be considered as if they were system headers. - drone.io changes: remove llvm 6.0 from clang config in drone.io and link flang with libstdc++ instead of libc++ llvm-dev resolved to llvm-6.0 in clang builds on drone.io. llvm 6.0 too old. LLVM packages are linked with libstdc++ standard library whereas libc++ was used for flang. This caused link time failure when building clang. Change frone.io to build flang with libc++. Note: This commit does not reflect an actual work log, it is a feature based split of the changes done in the FIR experimental branch. The related work log can be found in the commits between: 864898c and 137c23d Other changes come from flang-compiler#959 review.
jeanPerier
force-pushed
the
jpr-mono-split
branch
from
ee469d6 to
edb0943
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR contains the directory structure and .clang-format for FIR and the first piece of code: the ASTBuilder.
The ASTBuilder structure is a transient data structure that
is meant to be built from the parse tree just before lowering to
FIR and that will be deleted just afterwards. It is not meant to perform
optimization analysis and transformations. It only provides temporary
information, such as label target information or parse tree parent nodes,
that is meant to be used to lower the parse tree structure into
FIR operations.
A pretty printer is available to visualize this data structure.
This code depends on LLVM LLVMSupport library but does not require MLIR (it can build without changes to the current main
CMakeLists.txt).Note that the commits does not reflect an actual work log, it is a feature based split of the
changes done in the FIR experimental branch. The related work log can be found in the commits between: 8c320e3 and 9b9ea05.