You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[flang][MLIR][OpenMP] Extend delayed privatization for allocatables
Adds delayed privatization support for allocatables. In order to explain
the problem this diff is trying to solve, it would be useful to see an
example of `firstprivate` for an alloctable and how it is currently
emitted by flang **without** delayed privatization.
Consider the following Fortran code:
```fortran
subroutine delayed_privatization_allocatable
implicit none
integer, allocatable :: var1
!$omp parallel firstprivate(var1)
var1 = 10
!$omp end parallel
end subroutine
```
You would get something like this (again no delayed privatization yet):
```mlir
...
%3:2 = hlfir.declare %0 {fortran_attrs = #fir.var_attrs<allocatable>, ...} : ...
omp.parallel {
// Allocation logic
...
%9 = fir.load %3#1 : !fir.ref<!fir.box<!fir.heap<i32>>>
...
fir.if %12 {
...
} else {
...
}
%13:2 = hlfir.declare %8 {fortran_attrs = #fir.var_attrs<allocatable>, ...} : ...
// Copy logic
%14 = fir.load %13#0 : !fir.ref<!fir.box<!fir.heap<i32>>>
...
fir.if %17 {
%24 = fir.load %3#0 : !fir.ref<!fir.box<!fir.heap<i32>>>
...
}
...
omp.terminator
}
```
Note that for both the original and the private declaration, the
allocation and copy logic use both elements (e.g. `%3#0` and `%3#1`).
This poses the following problem for delayed privatization: how can
capture both values in order to pass them to the outlined privatizer?
The main issue is that `hlfir.declare` returns 2 SSA values that not
encapsulated together under a single composite value.
Some possible solutions are:
1. Change the return type of `hlfir.declare`. However, this would be
very invasive and therefore does not sound like a good idea.
2. Use the built-in `tuple` type to "pack" both values together. This is
reasonable but not very flexible since we won't be able to express
other information about the encapsulated values such as whether it is
alloctable.
3. Introduce a new concept/type that allows us to do the encapsulation
in a more flexible way. This is the "variable shadow" concept
introduced by this PR.
A "variable shadow" is a composite value of a special type:
`!fir.shadow` that has some special properties:
* It can be constructed only from `BlockArgument`s.
* It always has the type `!fir.shadow`.
* It packs the required information needed by the delayed privatizer
that correspond to the result of `hlfir.declare` operation.
We don't introduce any special opertions to deal with shadow values.
Rather we treat them similar to other composites. If you want to get a
certain component, use `fir.extract_value`. If you want to populate a
certain component, use `fir.insert_value`.
0 commit comments