Similar to #135415.
The spec has not strict restriction to allow a single `if_present`
clause on the host_data and update directives. Allowing this clause
multiple times does not change the semantic of it. This patch relax the
rules in ACC.td since there is no restriction in the standard.
The OpenACC dialect represents the `if_present` clause with a `UnitAttr`
so the attribute will be set if the is one or more `if_present` clause.
The spec has not strict restriction to allow a single `finalize` clause
on the `exit data` directive. Allowing this clause multiple times does
not change the semantic of it. This patch relax the rules in `ACC.td`
since there is no restriction in the standard.
The OpenACC dialect represent the finalize clause with a UnitAttr so the
attribute will be set if the is one or more `finalize` clause.
shortloop is a non standard OpenACC extension
(https://docs.nvidia.com/hpc-sdk/pgi-compilers/2015/pgirn157.pdf) that
can be found on loop directives.
f18 parser was choking when seeing it. Since it can be found in existing
apps and is mainly an optimization hint, parse it on loop directives and
ignore it with a warning.
For the records, here is shortloop meaning according to the manual linked above:
"If the shortloop clause appears on a loop directive with the vector clause, it tells the compiler that the
loop trip count is less than or equal to the number of vector lanes created for that loop. This means the
value of the vector() clause on the loop directive in a kernels region, or the value of the
vector_length() clause on the parallel directive in a parallel region will be greater than or
equal to the loop trip count. This allows the compiler to generate more efficient code for the loop"
2.9.1 The trip count for all loops associated with the collapse clause must be
computable and invariant in all the loops.
This patch checks that loops part of a collapse nest does not depends on outer
loops induction variables.
The check is also applied to combined construct with a loop.
2.9.1 The trip count for all loops associated with the collapse clause
must be computable and invariant in all the loops.
This patch checks that iteration range of loops part of a collapse nest
does not depend on outer loops induction variables.
The check is also applied to combined construct with a loop.
this patch enforce or fix the enforcement of two restrictions from
section 2.15.1:
> Only the gang, worker, vector, seq and bind clauses may follow a
device_type clause.
`seq` was not allowed after `device_type` with the current
implementation.
> Exactly one of the gang, worker, vector, or seq clauses must appear.
This was not properly checked. This patch check correctly for mutually
exclusion as described in section 2.4. Mutually exclusive clauses may
appear on the same directive if they apply for different device_type.
A couple of clauses are allowed multiple times when they are separated
by a device_type clause. This patch updates the ACC.td file to move
these clauses to the `allowedClause` list and the
`CheckAllowedOncePerGroup` function is used to make sure they appear
only once on the directive or for each device_type.
Some clauses can be repeated on the compute construct when they are
placed after `device_type`. The semantic check was reporting an error
for these cases. This patch fixes this.
Unlike mentioned in #73839, some OpenACC construct still need the cycle
branching check to be performed. This patch adds a list of construct
where the check is not needed (loop and combined construct) and add
tests to check where it is still needed.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
A var may appear at most once in all the clauses of declare directives
for a function, subroutine, program, or module.
We raise an error when a var appears in two different clauses. If it is
in the same clauses, we just issue a warning.
Some compilers allow the `$acc routine(<name>)` to be placed at the
program unit level. To be compatible, this patch enables the use of acc
routine at this level. These acc routine directives must have a name.
The symbol in bind clause on acc routine refers to a function or a
subroutine. This patch avoids to raise error when the function or
subroutine is declared later in the code or is external. This is in line
with normal procedure name resolution in Fortran code.
For portability with other compilers, just issue a portability warning
instead of a hard error when `num_gangs`, `num_workers` or
`vector_length` are present on an `!$acc serial` directive
During flang handling of semantics of OpenACC private/firstprivate/
reduction clauses (including the implicitly private loop IV), a new
scoped symbol was being created. This could lead to ambiguity in the
lowered FIR - aka having multiple fir.declare for the same symbol.
Because lowering of OpenACC does not materialize the meaning of the
private clauses (by actually creating a scoped local symbol), it does
not make sense to create a new symbol in semantics either.
I updated the acc-symbols01.f90 test to reflect this updated approach.
Technically, the test could be removed, but it made sense to keep in
place to highlight this intentional decision.
Relax the parser to accept scalar integer expression in addition to
scalar logical expression. The parser now accepts scalar expression and
the semantic checks its type.
This patch adds support for labeled do loop after combined directive. It
relaxes the initial parser and canonicalize labeled do loop into the
OpenACCCombinedConstruct.
Add semantic check for `!$acc atomic update`. RHS and LHS of the update
assignment must be scalar.
Without this check the code was going all the way to MLIR and trigger a
verifier error. This gives better user error message.
OpenACC 3.3 - 2.10 The cache directive may appear at the top of (inside
of) a loop.
This patch adds a semantic check to ensure the cache directive is inside
a loop.
Some compilers accept `!$acc data` without any clauses. For portability
reason, this patch relaxes the strict error to a simple portability warning.
Reviewed By: razvanlupusoru, vzakhari
Differential Revision: https://reviews.llvm.org/D159019
This reverts commit 02fa9fc018db5b757a4ce129d85d64efefc8645c.
Commit message and content does not match. Revert to commit with
a proper commit message.
Some compilers accept `!$acc end loop` associated with an `!$acc loop`
directive. This patch updates the acc loop parser to accept it as well.
The parser is also updated to be stricter on the following statement
to match the OpenACC combined construct parser.
The rewrite canonicalization is not a rewrite anymore and the naming
will be updated in a follow up patch for the Loop and Combined constructs.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D159015
The standard suggests that the value for the `device_type` clause on the
`set` directive is a list but this does not makes sense. Restrict the number
of value to one so it matches the runtime function.
Depends on D158644
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158645
This patch propagates the acc routine information
to the module file so they can be used by the caller.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158541
This restriction is not clearly stated in the OpenACC standard
but all other compilers enforce it and there no explanation to
what should happen if there is a branching out of the construct.
Add the restriction for now.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D158319
Distinguish between copyin and copyin with the readonly modifier.
Depends on D157121
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157125
F18 produce a module file with a declaration part. This patch
propagates the OpenACC declare information in the module file along the variable
declaration.
Depends on D157042
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157121
Flags were not correctly set for symbols appearing in the OpenACC declare
directive in module declaration part.
Also some missing flags for OpenACC are added. This makes the Flags enum
> 64 and then the implementation switch to std::bitset as defined in
`flang/include/flang/Common/enum-set.h`. Therefore, `constexpr` cannot be
used for set of flags in `flang/lib/Semantics/resolve-directives.cpp`.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157042
Enforce the following restriction specified in 2.13
A var may appear at most once in all the clauses of declare directives for a
function, subroutine, program, or module.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156945
The OpenACC 3.3 specification does not allow the `zero` modifier
on the `copyout` clause used with the declare directive.
This is similar to D156703 for the create clause.
This might be missing piece in the spec but we disallow it until proven otherwise.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156825
The OpenACC 3.3 specification does not allow the `zero` modifier
on the `create` clause used with the declare directive.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156703
Check the combination of reduction operator and types. This is
currently not checking common block and composite types.
Depends on D155105
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D155106
The following error was triggered in the added test case.
This is a false positive.
COMMON block must be declared in the same scoping unit in which the OpenACC directive or clause appears
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D154742
