OpenACC 3.2 allowed the wait clause to the data construct. This patch
adds a unit attribute and a variadic operand to the data operation to model
the wait clause in a similar way it was added to other data operation.
The attribute models the presence of the clause without any argument. When
arguments are provided they are placed in the wait operand.
Depends on D154111
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D154131
OpenACC 3.2 allowed the async clause to the data construct. This patch
adds a unit attribute and an optional operand to the data operation to model
the data clause in a similar way it was added to other data operation.
The attribute models the presence of the clause without any argument. When
an argument is provided it is placed in the async operand.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D154111
In the latest spec, the `num_gangs` clause accepts up to three
arguments. Update the dialect to swicth `numGangs` operands from
optional single operand to a variadic operand. The verifier limits
the number of operands to three as specified in the spec.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D153796
Lower 1d array reduction for add and mul operator. Multi-dimensional arrays and
other operator will follow.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D153448
acc.firstprivate operation will be used as data entry operation
for the firstprivate operands.
Depends on D152970
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D152972
acc.private operation will be used as data entry operation
for the private operands.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D152970
Use the new firstprivate representation on the comupte construct.
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151975
OpenACC 3.3 introduces a dim argument on the gang clause. This patch
adds a new operand for it on the acc.loop and update the custom
gang clause parser/printer for it.
Depends on D151970
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151971
The custom parser for the gang values was not implemented correctly.
This patch fixes the noted issue and allows the num/static values
to appear in any order.
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151970
Use the new reduction design in acc.loop operation.
Depends on D151146
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151164
Add the missing check on private list information. The
check is the same than the one done for acc.parallel.
Depends on D151146
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151149
Add the missing check on private list information. The
check is the same than the one done for acc.parallel.
Depends on D151146
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151149
After D150818 the reduction clause is represented
with a acc.reduction.recipe operation and an operand.
This patch updates the acc.parallel op for the new design.
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151146
The destroy region is optional but the verifier was enforcing it.
Update the verifier and make it clear in the definition.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D151239
Update acc.serial private operands list to use the new design
introduced in D150622.
Test in flang/test/Lower/OpenACC/acc-parallel.f90 and
flang/test/Lower/OpenACC/acc-parallel-loop.f90 are temporarly
disabled and will be enabled with updated lowering in the next
patch.
Depends on D150971
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D150972
Update acc.parallel private operands list to use the new design
introduced in D150622.
Test in flang/test/Lower/OpenACC/acc-parallel.f90 and
flang/test/Lower/OpenACC/acc-parallel-loop.f90 are temporarly
disabled and will be enabled with updated lowering in the follow-up
patch.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D150971
Similarly to D150622 for private clause, the reduction is currently not
modeled in a good way. This patch is inspired by the reduction representation
in the omp dialect (D105358) and make a new representation for the reduction in
the OpenACC dialect.
A new operation is introduced to model the sequences of operation needed to
initialize a local reduction value and how to combine two values during the
reduction. The operation requires two mandatory regions.
1. The init region specifies how to initialize the local reduction
value. The region has an argument that contains the value of the
reduction accumulator at the start of the reduction. It is expected to
`acc.yield` the new value.
2. The reduction region contains a sequences of operations to combine two
values of the reduction type into one. It has two arguments and it is
expected to `acc.yield` the combined value.
Example:
```mlir
acc.reduction.recipe @reduction_add_i64 : i64 init reduction_operator<add> {
^bb0(%0: i64):
// init region contains a sequence of operations to initialize the local
// reduction value as specified in 2.5.15
%c0 = arith.constant 0 : i64
acc.yield %c0 : i64
} reduction {
^bb0(%0: i64, %1: i64)
// reduction region contains a sequence of operations to combine
// two values into one.
%2 = arith.addi %0, %1 : i64
acc.yield %2 : i64
}
// The reduction symbol is then used in the corresponding operation.
acc.parallel reduction(@reduction_add_i64 -> %a : i64) {
}
Reviewed By: razvanlupusoru, vzakhari
Differential Revision: https://reviews.llvm.org/D150818
Add a representation for firstprivate clause modeled on the
private representation added in D150622.
The firstprivate recipe operation has an additional mandatory
region representing a sequences of operations needed to copy
the initial value to the created private copy.
Depends on D150622
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D150729
Currently privatization is not well represented in the OpenACC dialect. This
patch is a prototype to model privatization with a dedicated operation that
declares how the private value is created and destroyed.
The newly introduced operation is `acc.private.recipe` and it declares
an OpenACC privatization. The operation requires one mandatory and
one optional region.
1. The initializer region specifies how to create and initialize a new
private value. For example in Fortran, a derived-type might have a
default initialization. The region has an argument that contains the
value that need to be privatized. This is useful if the type is not
a known at compile time and the private value is needed to create its
copy.
2. The destroy region specifies how to destruct the value when it reaches
its end of life. It takes the privatized value as argument.
A same privatization can be used for multiple operand if they have the same
type and do not require a specific default initialization.
Example:
```mlir
acc.private.recipe @privatization_f32 : f32 init {
^bb0(%0: f32):
// init region contains a sequence of operations to create and initialize the
// copy if needed.
} destroy {
^bb0(%0: f32):
// destroy region contains a sequences of operations to destruct the created
// copy.
}
// The privatization symbol is then used in the corresponding operation.
acc.parallel private(@privatization_f32 -> %a : f32) {
}
```
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D150622
Add if condition removal pattern for acc.host_data in a same way as
acc.enter_data, acc.exit_data and acc.update.
The condition is removed from the op if it is a true constant. If
it is a false constant then the region is inlined before the op
and the op is removed.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D150480
The acc.host_data operation models the OpenACC
host_data construct (2.8). The host_data construct
defines a region where the address of data in device memory
available on the host. The operation is modeled in a similar way
than acc.data operation.
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D150289
Remove old clause operands from acc.kernels operation since
the new dataOperands is now in place.
private and firstprivate will receive some redesign but are
not part of the new dataOperands.
Depends on D150224
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D150225
Remove old clause operands from acc.serial operation since
the new dataOperands is now in place.
private and firstprivate will receive some redesign but are
not part of the new dataOperands.
Depends on D150207
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D150224
Remove old clause operands from acc.parallel operation since
the new dataOperands is now in place.
private, firstprivate and reductions will receive some redesign but are
not part of the new dataOperands.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D150207
Since the new data operand operations have been added in D148389 and
adopted on acc.data in D149673, the old clause operands are no longer
needed.
The LegalizeDataOpForLLVMTranslation will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.
processOperands will also receive some updates once all the operands
will be coming from an acc data operand operation.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D150155
Since the new data operand operations have been added in D148389 and
adopted on acc.exit_data in D149601, the old clause operands are no longer
needed.
The LegalizeDataOpForLLVMTranslation will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.
processOperands will also receive some updates once all the operands
will be coming from an acc data operand operation.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D150145
Since the new data operand operations have been added in D148389 and
adopted on acc.enter_data in D148721, the old clause operands are no longer
needed.
The LegalizeDataOpForLLVMTranslation will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.
processOperands will also receive some updates once all the operands
will be coming from an acc data operand operation.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D150132
Since the new data operand operations have been added in D148389 and
adopted on acc.update in D149909, the old clause operands are no longer
needed. This is a first patch to start cleaning the OpenACC operations
with data clause operands.
The `LegalizeDataOpForLLVMTranslation` will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.
`processOperands` will also receive some updates once all the operands
will be coming from an acc data operand operation.
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D150053
Data operands associated with acc.parallel, acc.serial and
acc.kernels should comes from acc data entry/exit operations
or acc.getdeviceptr.
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D149994
Data operands associated with acc.update should comes
from acc data entry/exit operations or acc.getdeviceptr.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D149990
Data operands associated with acc.enter_data should comes
from acc data entry operations.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D149991
Data operands associated with acc.data should comes
from acc data entry/exit operations or acc.getdeviceptr.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D149992
Introduce acc.update_host and acc.update_device as data
operands operation to be used by the acc.update op.
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D149909
Values in bounds are expected to have integer or index types. Enforce
this expectation by restricting the type to be IntOrIndex.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D148839
The data operations added in D148389 hold two data clause fields:
"dataClause" and "decomposedFrom". However, in most cases, dataClause
field holds a default value (except for acc_copyin_readonly,
acc_create_zero, and acc_copyout_zero).
The decomposedFrom field holds the original clause specified by user.
As work began on lowering to these new operations [1], it seems that
having both fields adds a bit of ambiguity. There is only one scenario
where we actually intended to use both:
acc data copyout(zero:)
The original intent was that this clause would be decomposed to
the following operations:
acc.create {dataClause = acc_create_zero, decomposedFrom =
acc_copyout_zero}
...
acc.copyout {dataClause = acc_copyout_zero}
However, we can encode the zero semantics like so without need of both:
acc.create {dataClause = acc_copyout_zero}
...
acc.copyout {dataClause = acc_copyout_zero}
Thus get rid of the decomposedFrom field and update verifier checks
to check for all data clauses that can be decomposed to the particular
operation.
So now the dataClause holds the original user's clause which simplifies
understanding of the operation.
[1] https://reviews.llvm.org/D148721
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D148731
As outlined in [1], data clauses are now implemented as separate operations
from the constructs that they belong to. Some of the highlighted benefits:
- Correctly represent dataflow of data operations
- Easier to track debugging information
- Friendlier to add attributes and to optimize operations
For now, all of the other operand lists are being kept until all references
to them in LLVM can be removed (such as those in flang lowering)
[1] https://discourse.llvm.org/t/rfc-openacc-dialect-data-operation-improvements/69825
Reviewed By: clementval, vzakhari
Differential Revision: https://reviews.llvm.org/D148389
Use the assembly format with custom parser/printer
for specific clauses instead of a full custom parser/printer.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D148391
Use the assembly format with custom parser/printer
for specific clauses instead of a full custom parser/printer.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D148391
The acc.kernels operation models the OpenACC kernels construct.
The kernels construct defines a region of a program that is
compiled into a sequence of kernels to be executed on the current device.
The operation is modelled on the acc.parallel operation and will
receive similar updates when the data operands operations will
be implemented.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D148277
acc.serial op is modeled on the acc.parallel op.
acc.yield operation must then accept acc.serial has a parent
operation.
Reviewed By: PeteSteinfeld, razvanlupusoru
Differential Revision: https://reviews.llvm.org/D148258
The acc.serial operation models the OpenACC serial construct.
The serial construct defines a region of a program that is to be
executed sequentially on the current device.
The operation is modelled on the acc.parallel operation and will
receive similar updates when the data operands operations will
be implemented.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D148250
Remove the custoom parser and printer for the acc.parallel
operation and use the assembly format directly.
Reviewed By: PeteSteinfeld, razvanlupusoru
Differential Revision: https://reviews.llvm.org/D148183
Use the oilist syntax in assembly format where appropriate.
This makes the dialect format more flexible as an order
is not imposed for the clauses.
Reviewed By: PeteSteinfeld, razvanlupusoru
Differential Revision: https://reviews.llvm.org/D148154
The acc.loop operation was constrained by the SingleBlockImplicitTerminator.
This patch relax this constraint to allow multiple block in the loop.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D148025
This new option is set to `false` by default. It should be set only in Canonicalizer tests to detect faulty canonicalization patterns. I.e., patterns that prevent the canonicalizer from converging. The canonicalizer should always convergence on such small unit tests that we have in `canonicalize.mlir`.
Two faulty canonicalization patterns were detected and fixed with this change.
Differential Revision: https://reviews.llvm.org/D140873
This commit refactors the syntax of "ugly" attribute/type formats to not use
strings for wrapping. This means that moving forward attirbutes and type formats
will always need to be in some recognizable form, i.e. if they use incompatible
characters they will need to manually wrap those in a string, the framework will
no longer do it automatically.
This has the benefit of greatly simplifying how parsing attributes/types work, given
that we currently rely on some extremely complicated nested parser logic which is
quite problematic for a myriad of reasons; unecessary complexity(we create a nested
source manager/lexer/etc.), diagnostic locations can be off/wrong given string escaping,
etc.
Differential Revision: https://reviews.llvm.org/D118505
