| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in ALLOCATE (#165865) The ALLOCATE directive has two forms: - A declarative form with a standalone directive: !$OMP ALLOCATE (variable-list-item...) - An executable form that consists of several directives followed by an ALLOCATE statement: !$OMP ALLOCATE (variable-list-item...) !$OMP ALLOCATE (variable-list-item...) ... ALLOCATE (...) The second form was deprecated in OpenMP 5.2 in favor of the ALLOCATORS construct. Since in the parse tree every type corresponding to a directive only corresponds to a single directive, the executable form is represented by a sequence of nested OmpAllocateDirectives, e.g. !$OMP ALLOCATE(x) !$OMP ALLOCATE(y) ALLOCATE(x, y) will become `` OmpAllocateDirective |- ALLOCATE(x) // begin directive - OmpAllocateDirective // block |- ALLOCATE(y) // begin directive - ALLOCATE(x, y) // block `` With this change all AST nodes for directives use OmpDirectiveSpecification as the directive representation. | 9 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in ALLOCATE (#165865) The ALLOCATE directive has two forms: - A declarative form with a standalone directive: !$OMP ALLOCATE (variable-list-item...) - An executable form that consists of several directives followed by an ALLOCATE statement: !$OMP ALLOCATE (variable-list-item...) !$OMP ALLOCATE (variable-list-item...) ... ALLOCATE (...) The second form was deprecated in OpenMP 5.2 in favor of the ALLOCATORS construct. Since in the parse tree every type corresponding to a directive only corresponds to a single directive, the executable form is represented by a sequence of nested OmpAllocateDirectives, e.g. !$OMP ALLOCATE(x) !$OMP ALLOCATE(y) ALLOCATE(x, y) will become `` OmpAllocateDirective |- ALLOCATE(x) // begin directive - OmpAllocateDirective // block |- ALLOCATE(y) // begin directive - ALLOCATE(x, y) // block `` With this change all AST nodes for directives use OmpDirectiveSpecification as the directive representation. | 9 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in ALLOCATE (#165865) The ALLOCATE directive has two forms: - A declarative form with a standalone directive: !$OMP ALLOCATE (variable-list-item...) - An executable form that consists of several directives followed by an ALLOCATE statement: !$OMP ALLOCATE (variable-list-item...) !$OMP ALLOCATE (variable-list-item...) ... ALLOCATE (...) The second form was deprecated in OpenMP 5.2 in favor of the ALLOCATORS construct. Since in the parse tree every type corresponding to a directive only corresponds to a single directive, the executable form is represented by a sequence of nested OmpAllocateDirectives, e.g. !$OMP ALLOCATE(x) !$OMP ALLOCATE(y) ALLOCATE(x, y) will become `` OmpAllocateDirective |- ALLOCATE(x) // begin directive - OmpAllocateDirective // block |- ALLOCATE(y) // begin directive - ALLOCATE(x, y) // block `` With this change all AST nodes for directives use OmpDirectiveSpecification as the directive representation. | 9 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in ALLOCATE (#165865) The ALLOCATE directive has two forms: - A declarative form with a standalone directive: !$OMP ALLOCATE (variable-list-item...) - An executable form that consists of several directives followed by an ALLOCATE statement: !$OMP ALLOCATE (variable-list-item...) !$OMP ALLOCATE (variable-list-item...) ... ALLOCATE (...) The second form was deprecated in OpenMP 5.2 in favor of the ALLOCATORS construct. Since in the parse tree every type corresponding to a directive only corresponds to a single directive, the executable form is represented by a sequence of nested OmpAllocateDirectives, e.g. !$OMP ALLOCATE(x) !$OMP ALLOCATE(y) ALLOCATE(x, y) will become `` OmpAllocateDirective |- ALLOCATE(x) // begin directive - OmpAllocateDirective // block |- ALLOCATE(y) // begin directive - ALLOCATE(x, y) // block `` With this change all AST nodes for directives use OmpDirectiveSpecification as the directive representation. | 9 个月前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in ASSUMES (#160591) | 10 个月前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Canonicalize loops with intervening OpenMP constructs (#169191) Example based on the gfortran test a.6.1.f90 do 100 i = 1,10 !$omp do do 100 j = 1,10 call work(i,j) 100 continue During canonicalization of label-DO loops, if the body of an OpenMP construct ends with a label, treat the label as ending the construct itself. This will also allow handling of cases like do 100 i = 1, 10 !$omp atomic write 100 x = i which we were unable to before. | 8 个月前 | |
[flang][OpenMP]Add support for fail clause (#118683) Support the atomic compare option of a fail(memory-order) clauses. Additional tests introduced to check that parsing and semantics checks for the new clause is handled. Lowering for atomic compare is still unsupported and wil end in a TOOD (aka "Not yet implemented"). A test for this case with the fail clause is also present. | 1 年前 | |
[flang][OpenMP] Store Block in OpenMPLoopConstruct, add access functions (#168078) Instead of storing a variant with specific types, store parser::Block as the body. Add two access functions to make the traversal of the nest simpler. This will allow storing loop-nest sequences in the future. | 8 个月前 | |
[flang][OpenMP] Replace OpenMPBlockConstruct with OmpBlockConstruct (#155872) OpenMPBlockConstruct, somewhat confusingly, represents most but not all block-associated constructs. It's derived from OmpBlockConstruct, as are all the remaining block-associated constructs. It does not correspond to any well-defined group of constructs. It's the collection of constructs that don't have their own types (and those that do have their own types do so for their own reasons). Using the broader OmpBlockConstruct in type-based visitors won't cause issues, because the specific overloads (for classes derived from it) will always be preferred. | 11 个月前 | |
[flang] Further refinement of OpenMP !$ lines in -E mode (#138956) Address failing Fujitsu test suite cases that were broken by the patch to defer the handling of !$ lines in -fopenmp vs. normal compilation to actual compilation rather than processing them immediately in -E mode. Tested on the samples in the bug report as well as all of the Fujitsu tests that I could find that use !$ lines. Fixes https://github.com/llvm/llvm-project/issues/136845. | 1 年前 | |
[flang][Parser][OpenMP] Fix unparser for cancellation_construct_type (#136001) Previously the unparser would print like !$OMP CANCEL CANCELLATION_CONSTRUCT_TYPE(SECTIONS) This is not valid Fortran. I have fixed it to print without the clause name. | 1 年前 | |
[flang] Further refinement of OpenMP !$ lines in -E mode (#138956) Address failing Fujitsu test suite cases that were broken by the patch to defer the handling of !$ lines in -fopenmp vs. normal compilation to actual compilation rather than processing them immediately in -E mode. Tested on the samples in the bug report as well as all of the Fujitsu tests that I could find that use !$ lines. Fixes https://github.com/llvm/llvm-project/issues/136845. | 1 年前 | |
[flang][openmp] Handle !$INCLUDE "foo" (bug #64128) Detect and process INCLUDE lines that are guarded by OpenMP conditional compilation markers (!$), when enabled. Fixes https://github.com/llvm/llvm-project/issues/64128. Differential Revision: https://reviews.llvm.org/D156759 | 2 年前 | |
[flang][openmp] Handle !$INCLUDE "foo" (bug #64128) Detect and process INCLUDE lines that are guarded by OpenMP conditional compilation markers (!$), when enabled. Fixes https://github.com/llvm/llvm-project/issues/64128. Differential Revision: https://reviews.llvm.org/D156759 | 2 年前 | |
[flang][OpenMP] Replace OpenMPBlockConstruct with OmpBlockConstruct (#155872) OpenMPBlockConstruct, somewhat confusingly, represents most but not all block-associated constructs. It's derived from OmpBlockConstruct, as are all the remaining block-associated constructs. It does not correspond to any well-defined group of constructs. It's the collection of constructs that don't have their own types (and those that do have their own types do so for their own reasons). Using the broader OmpBlockConstruct in type-based visitors won't cause issues, because the specific overloads (for classes derived from it) will always be preferred. | 11 个月前 | |
[flang][OpenMP] Make OpenMPCriticalConstruct follow block structure (#152007) This allows not having the END CRITICAL directive in certain situations. Update semantic checks and symbol resolution. | 11 个月前 | |
[flang][OpenMP] Canonicalize loops with intervening OpenMP constructs (#169191) Example based on the gfortran test a.6.1.f90 do 100 i = 1,10 !$omp do do 100 j = 1,10 call work(i,j) 100 continue During canonicalization of label-DO loops, if the body of an OpenMP construct ends with a label, treat the label as ending the construct itself. This will also allow handling of cases like do 100 i = 1, 10 !$omp atomic write 100 x = i which we were unable to before. | 8 个月前 | |
[OpenMP][Flang] Change the OmpDefaultMapperName suffix (#168399) This PR fixes a Fortran syntax violation in the OpenMP default mapper naming convention. The suffix .omp.default.mapper contains dots which are invalid in Fortran identifiers, causing failures when mappers are written to and read from module files. The fix changes the suffix to _omp_default_mapper which uses underscores instead of dots, complying with Fortran syntax rules. Key changes: - Changed OmpDefaultMapperName constant from .omp.default.mapper to _omp_default_mapper - Added GetUltimate() calls in mapper symbol resolution to properly handle symbols across module boundaries - Added new test case verifying default mappers work correctly when defined in a module and used in consuming programs This fixes #168336. | 8 个月前 | |
[flang][OpenMP] Store Block in OpenMPLoopConstruct, add access functions (#168078) Instead of storing a variant with specific types, store parser::Block as the body. Add two access functions to make the traversal of the nest simpler. This will allow storing loop-nest sequences in the future. | 8 个月前 | |
[flang][OpenMP] Implement OpenMP stylized expressions (#165049) Consider OpenMP stylized expression to be a template to be instantiated with a series of types listed on the containing directive (currently DECLARE_REDUCTION). Create a series of instantiations in the parser, allowing OpenMP special variables to be declared separately for each type. --------- Co-authored-by: Tom Eccles <tom.eccles@arm.com> | 9 个月前 | |
[flang][OpenMP] Implement OpenMP stylized expressions (#165049) Consider OpenMP stylized expression to be a template to be instantiated with a series of types listed on the containing directive (currently DECLARE_REDUCTION). Create a series of instantiations in the parser, allowing OpenMP special variables to be declared separately for each type. --------- Co-authored-by: Tom Eccles <tom.eccles@arm.com> | 9 个月前 | |
[flang][OpenMP] Store Block in OpenMPLoopConstruct, add access functions (#168078) Instead of storing a variant with specific types, store parser::Block as the body. Add two access functions to make the traversal of the nest simpler. This will allow storing loop-nest sequences in the future. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in DECLARE_TARGET (#160573) | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in DECLARE_TARGET (#160573) | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in DECLARE_VARIANT (#160371) | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in DECLARE_TARGET (#160573) | 10 个月前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in standalone directives (#131163) This uses OmpDirectiveSpecification in the rest of the standalone directives. | 1 年前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Store Block in OpenMPLoopConstruct, add access functions (#168078) Instead of storing a variant with specific types, store parser::Block as the body. Add two access functions to make the traversal of the nest simpler. This will allow storing loop-nest sequences in the future. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Replace modifiers in DYN_GROUPPRIVATE clause (#166199) The "prescriptiveness" modifier has been replaced with "fallback-modifier". The "fallback" value has been removed from the "prescriptiveness" modifier. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in DECLARE_TARGET (#160573) | 10 个月前 | |
[flang][OpenMP] Allow utility constructs in specification part (#121509) Allow utility constructs (error and nothing) to appear in the specification part as well as the execution part. The exception is "ERROR AT(EXECUTION)" which should only be in the execution part. In case of ambiguity (the boundary between the specification and the execution part), utility constructs will be parsed as belonging to the specification part. In such cases move them to the execution part in the OpenMP canonicalization code. | 1 年前 | |
[flang][OpenMP] Parse ORDERED as standalone when DEPEND/DOACROSS is p… (#156693) …resent The OpenMP spec 4.5-5.1 defines ORDERED as standalone when a DEPEND clause is present (with either SOURCE or SINK as argument). The OpenMP spec 5.2+ defines ORDERED as standalone when a DOACROSS clause is present. | 10 个月前 | |
[flang][OpenMP] Better diagnostics for invalid or misplaced directives (#168885) Add two more AST nodes, one for a misplaced end-directive, and one for an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ"). Emit error messages when either node is encountered in semantic analysis. | 8 个月前 | |
[flang][OpenMP] Implement loop nest parser (#168884) Previously, loop constructs were parsed in a piece-wise manner: the begin directive, the body, and the end directive were parsed separately. Later on in canonicalization they were all coalesced into a loop construct. To facilitate that end-loop directives were given a special treatment, namely they were parsed as OpenMP constructs. As a result syntax errors caused by misplaced end-loop directives were handled differently from those cause by misplaced non-loop end directives. The new loop nest parser constructs the complete loop construct, removing the need for the canonicalization step. Additionally, it is the basis for parsing loop-sequence-associated constructs in the future. It also removes the need for the special treatment of end-loop directives. While this patch temporarily degrades the error messaging for misplaced end-loop directives, it enables uniform handling of any misplaced end-directives in the future. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in simple directives (#131162) The OmpDirectiveSpecification contains directive name, the list of arguments, and the list of clauses. It was introduced to store the directive specification in METADIRECTIVE, and could be reused everywhere a directive representation is needed. In the long term this would unify the handling of common directive properties, as well as creating actual constructs from METADIRECTIVE by linking the contained directive specification with any associated user code. | 1 年前 | |
[Flang][OpenMP] Add semantic support for Loop Sequences and OpenMP loop fuse (#161213) This patch adds semantics for the omp fuse directive in flang, as specified in OpenMP 6.0. This patch also enables semantic support for loop sequences which are needed for the fuse directive along with semantics for the looprange clause. These changes are only semantic. Relevant tests have been added , and previous behavior is retained with no changes. --------- Co-authored-by: Ferran Toda <ferran.todacasaban@bsc.es> Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com> | 8 个月前 | |
[Flang][OpenMP] Add semantic support for Loop Sequences and OpenMP loop fuse (#161213) This patch adds semantics for the omp fuse directive in flang, as specified in OpenMP 6.0. This patch also enables semantic support for loop sequences which are needed for the fuse directive along with semantics for the looprange clause. These changes are only semantic. Relevant tests have been added , and previous behavior is retained with no changes. --------- Co-authored-by: Ferran Toda <ferran.todacasaban@bsc.es> Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com> | 8 个月前 | |
[Flang][OpenMP] Add semantic support for Loop Sequences and OpenMP loop fuse (#161213) This patch adds semantics for the omp fuse directive in flang, as specified in OpenMP 6.0. This patch also enables semantic support for loop sequences which are needed for the fuse directive along with semantics for the looprange clause. These changes are only semantic. Relevant tests have been added , and previous behavior is retained with no changes. --------- Co-authored-by: Ferran Toda <ferran.todacasaban@bsc.es> Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com> | 8 个月前 | |
[flang][OpenMP] Parse GROUPPRIVATE directive (#153807) No semantic checks or lowering yet. | 11 个月前 | |
[flang][OpenMP] Use new modifiers in IF/LASTPRIVATE (#118128) The usual changes, added more references to OpenMP specs. | 1 年前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
| 1 年前 | ||
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in DECLARE_SIMD (#160390) | 10 个月前 | |
[flang][OpenMP] Implement loop nest parser (#168884) Previously, loop constructs were parsed in a piece-wise manner: the begin directive, the body, and the end directive were parsed separately. Later on in canonicalization they were all coalesced into a loop construct. To facilitate that end-loop directives were given a special treatment, namely they were parsed as OpenMP constructs. As a result syntax errors caused by misplaced end-loop directives were handled differently from those cause by misplaced non-loop end directives. The new loop nest parser constructs the complete loop construct, removing the need for the canonicalization step. Additionally, it is the basis for parsing loop-sequence-associated constructs in the future. It also removes the need for the special treatment of end-loop directives. While this patch temporarily degrades the error messaging for misplaced end-loop directives, it enables uniform handling of any misplaced end-directives in the future. | 8 个月前 | |
[flang][OpenMP] Implement loop nest parser (#168884) Previously, loop constructs were parsed in a piece-wise manner: the begin directive, the body, and the end directive were parsed separately. Later on in canonicalization they were all coalesced into a loop construct. To facilitate that end-loop directives were given a special treatment, namely they were parsed as OpenMP constructs. As a result syntax errors caused by misplaced end-loop directives were handled differently from those cause by misplaced non-loop end directives. The new loop nest parser constructs the complete loop construct, removing the need for the canonicalization step. Additionally, it is the basis for parsing loop-sequence-associated constructs in the future. It also removes the need for the special treatment of end-loop directives. While this patch temporarily degrades the error messaging for misplaced end-loop directives, it enables uniform handling of any misplaced end-directives in the future. | 8 个月前 | |
[flang][OpenMP] Store Block in OpenMPLoopConstruct, add access functions (#168078) Instead of storing a variant with specific types, store parser::Block as the body. Add two access functions to make the traversal of the nest simpler. This will allow storing loop-nest sequences in the future. | 8 个月前 | |
[Flang][OpenMP] Add semantic support for Loop Sequences and OpenMP loop fuse (#161213) This patch adds semantics for the omp fuse directive in flang, as specified in OpenMP 6.0. This patch also enables semantic support for loop sequences which are needed for the fuse directive along with semantics for the looprange clause. These changes are only semantic. Relevant tests have been added , and previous behavior is retained with no changes. --------- Co-authored-by: Ferran Toda <ferran.todacasaban@bsc.es> Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com> | 8 个月前 | |
[Flang][OpenMP] Add semantic support for Loop Sequences and OpenMP loop fuse (#161213) This patch adds semantics for the omp fuse directive in flang, as specified in OpenMP 6.0. This patch also enables semantic support for loop sequences which are needed for the fuse directive along with semantics for the looprange clause. These changes are only semantic. Relevant tests have been added , and previous behavior is retained with no changes. --------- Co-authored-by: Ferran Toda <ferran.todacasaban@bsc.es> Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com> | 8 个月前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Frontend support for ATTACH modifier (#163608) Add parsing, semantic checks, but no lowering. | 9 个月前 | |
[Flang][OpenMP] Update declare mapper lookup via use-module (#167903) | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Implement OpenMP stylized expressions (#165049) Consider OpenMP stylized expression to be a template to be instantiated with a series of types listed on the containing directive (currently DECLARE_REDUCTION). Create a series of instantiations in the parser, allowing OpenMP special variables to be declared separately for each type. --------- Co-authored-by: Tom Eccles <tom.eccles@arm.com> | 9 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in standalone directives (#131163) This uses OmpDirectiveSpecification in the rest of the standalone directives. | 1 年前 | |
[flang][OpenMP] Implement OmpDirectiveName, use in OmpDirectiveSpecif… (#130121) …ication The OmpDirectiveName class has a source in addition to wrapping the llvm::omp::Directive. | 1 年前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in METADIRECTIVE (#159577) | 10 个月前 | |
[Flang] [OpenMP] Add support for spaces in between the name (#168311) Supports the fixed form syntax which has spaces in between the identifier | 8 个月前 | |
| 8 个月前 | ||
[Flang][OpenMP] NFC: Move OpenMP parser tests to a sub-directory Now that the test files are in the OpenMP subdirectory, remove the omp prefix. | 3 年前 | |
[flang][OpenMP] Allow utility constructs in specification part (#121509) Allow utility constructs (error and nothing) to appear in the specification part as well as the execution part. The exception is "ERROR AT(EXECUTION)" which should only be in the execution part. In case of ambiguity (the boundary between the specification and the execution part), utility constructs will be parsed as belonging to the specification part. In such cases move them to the execution part in the OpenMP canonicalization code. | 1 年前 | |
[OpenMP][Flang] Change the OmpDefaultMapperName suffix (#168399) This PR fixes a Fortran syntax violation in the OpenMP default mapper naming convention. The suffix .omp.default.mapper contains dots which are invalid in Fortran identifiers, causing failures when mappers are written to and read from module files. The fix changes the suffix to _omp_default_mapper which uses underscores instead of dots, complying with Fortran syntax rules. Key changes: - Changed OmpDefaultMapperName constant from .omp.default.mapper to _omp_default_mapper - Added GetUltimate() calls in mapper symbol resolution to properly handle symbols across module boundaries - Added new test case verifying default mappers work correctly when defined in a module and used in consuming programs This fixes #168336. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Parse ORDERED as standalone when DEPEND/DOACROSS is p… (#156693) …resent The OpenMP spec 4.5-5.1 defines ORDERED as standalone when a DEPEND clause is present (with either SOURCE or SINK as argument). The OpenMP spec 5.2+ defines ORDERED as standalone when a DOACROSS clause is present. | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Replace OpenMPBlockConstruct with OmpBlockConstruct (#155872) OpenMPBlockConstruct, somewhat confusingly, represents most but not all block-associated constructs. It's derived from OmpBlockConstruct, as are all the remaining block-associated constructs. It does not correspond to any well-defined group of constructs. It's the collection of constructs that don't have their own types (and those that do have their own types do so for their own reasons). Using the broader OmpBlockConstruct in type-based visitors won't cause issues, because the specific overloads (for classes derived from it) will always be preferred. | 11 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Frontend support for REPLAYABLE and TRANSPARENT clauses (#158149) Parsing and semantic checks. | 10 个月前 | |
[flang][OpenMP] Frontend support for DEVICE_SAFESYNC (#163560) Add parsing and semantic checks for DEVICE_SAFESYNC clause. No lowering. | 9 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in simple directives (#131162) The OmpDirectiveSpecification contains directive name, the list of arguments, and the list of clauses. It was introduced to store the directive specification in METADIRECTIVE, and could be reused everywhere a directive representation is needed. In the long term this would unify the handling of common directive properties, as well as creating actual constructs from METADIRECTIVE by linking the contained directive specification with any associated user code. | 1 年前 | |
[flang][OpenMP] Replace OpenMPBlockConstruct with OmpBlockConstruct (#155872) OpenMPBlockConstruct, somewhat confusingly, represents most but not all block-associated constructs. It's derived from OmpBlockConstruct, as are all the remaining block-associated constructs. It does not correspond to any well-defined group of constructs. It's the collection of constructs that don't have their own types (and those that do have their own types do so for their own reasons). Using the broader OmpBlockConstruct in type-based visitors won't cause issues, because the specific overloads (for classes derived from it) will always be preferred. | 11 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in SECTIONS (#159580) | 10 个月前 | |
[flang] Further refinement of OpenMP !$ lines in -E mode (#138956) Address failing Fujitsu test suite cases that were broken by the patch to defer the handling of !$ lines in -fopenmp vs. normal compilation to actual compilation rather than processing them immediately in -E mode. Tested on the samples in the bug report as well as all of the Fujitsu tests that I could find that use !$ lines. Fixes https://github.com/llvm/llvm-project/issues/136845. | 1 年前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in simple directives (#131162) The OmpDirectiveSpecification contains directive name, the list of arguments, and the list of clauses. It was introduced to store the directive specification in METADIRECTIVE, and could be reused everywhere a directive representation is needed. In the long term this would unify the handling of common directive properties, as well as creating actual constructs from METADIRECTIVE by linking the contained directive specification with any associated user code. | 1 年前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Use new modifiers with AFFINITY/ALIGNED/DEVICE (#117786) This is a mostly mechanical change from specific modifiers embedded directly in a clause to the Modifier variant. Additional comments and references to the OpenMP specs were added. | 1 年前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Make all block constructs share the same structure (#150956) The structure is - OmpBeginDirective (aka OmpDirectiveSpecification) - Block - optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>) The OmpBeginDirective and OmpEndDirective are effectively different names for OmpDirectiveSpecification. They exist to allow the semantic analyses to distinguish between the beginning and the ending of a block construct without maintaining additional context. The actual changes are in the parser: parse-tree.h and openmp-parser.cpp in particular. The rest is simply changing the way the directive/clause information is accessed (typically for the simpler). All standalone and block constructs now use OmpDirectiveSpecification to store the directive/clause information. | 1 年前 | |
[flang][OpenMP] Semantic checks for TASKGRAPH (#160115) This verifies the "structural" restrictions on constructs encountered in a TASKGRAPH construct. There are also restrictions that apply to list items, specifically in the following contexts: - a list item on a clause on a replayable construct, - data-sharing attributes for a variable on a replayable construct. These restrictions are not verified, because that would require knowing which clauses (on a potential compound directive) apply to the task- generating construct of interest. This information is not available during semantic checks. | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in THREADPRIVATE (#159632) Since ODS doesn't store a list of OmpObjects (i.e. not as OmpObjectList), some semantics-checking functions needed to be updated to operate on a single object at a time. | 10 个月前 | |
[flang][OpenMP] Better diagnostics for invalid or misplaced directives (#168885) Add two more AST nodes, one for a misplaced end-directive, and one for an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ"). Emit error messages when either node is encountered in semantic analysis. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[Flang] Add standalone tile support (#160298) Add support for the standalone OpenMP tile construct: f90 !$omp tile sizes(...) DO i = 1, 100 ... This is complementary to #143715 which added support for the tile construct as part of another loop-associated construct such as worksharing-loop, distribute, etc. | 10 个月前 | |
[flang][OpenMP] Store Block in OpenMPLoopConstruct, add access functions (#168078) Instead of storing a variant with specific types, store parser::Block as the body. Add two access functions to make the traversal of the nest simpler. This will allow storing loop-nest sequences in the future. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][OpenMP] Store Block in OpenMPLoopConstruct, add access functions (#168078) Instead of storing a variant with specific types, store parser::Block as the body. Add two access functions to make the traversal of the nest simpler. This will allow storing loop-nest sequences in the future. | 8 个月前 | |
[flang][OpenMP] Use OmpDirectiveSpecification in Omp[Begin|End]LoopDi… (#159087) …rective This makes accessing directive components, such as directive name or the list of clauses simpler and more uniform across different directives. It also makes the parser simpler, since it reuses existing parsing functionality. The changes are scattered over a number of files, but they all share the same nature: - getting the begin/end directive from OpenMPLoopConstruct, - getting the llvm::omp::Directive enum, and the source location, - getting the clause list. | 10 个月前 | |
[flang][openmp] Add parser and semantic support for workdistribute (#154377) This PR adds workdistribute parser and semantic support in flang. The work in this PR is c-p and updated from @ivanradanov commits from coexecute implementation: flang_workdistribute_iwomp_2024 | 11 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 11 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 11 个月前 |