[flang-commits] [flang] [OpenMP][Flang] Add "IsolatedFromAbove" trait to omp.target (PR #67164)

via flang-commits flang-commits at lists.llvm.org
Fri Oct 13 08:24:20 PDT 2023


agozillon wrote:

> > Perhaps I am misunderstanding what you mean (so my apologies if I am), but I believe this is already the case, map_info holds or is supposed to hold bounds information: https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td#L1149.
> > It is a little weird that we'd now end up creating a map_info for each bound which then has an empty bound though. I agree that it would be nice to not have to do that as it feels a bit like it defeats the purpose of a map_info owning a bound, but perhaps it's unavoidable.
> 
> What i am saying is, for the Fortran+OpenMP example below, the `map_info` generated should be the same as if the target directive was `!$omp target map(a(11,22))` or `!$omp target map(a)`. If we do it that way then all the bounds will be part of the `map_info` of `a(11,22)` or `a`. At the moment, I don't see bounds generated. I believe the relevant entry is the following and it does not have an `omp.bounds` for the `omp.map_info`.
> 
> ```
>    !CHECK: %[[VAL_6:.*]] = omp.map_info var_ptr(%[[VAL_5]]#1 : !fir.ref<!fir.array<?x1024xi32>>)   map_clauses(literal, implicit, exit_release_or_enter_alloc) capture(ByCopy) -> !fir.ref<!fir.array<?x1024xi32>> {name = "a"}
> ```
> 
> ```
>    integer :: n
>    integer :: a(n, 1024)
>    !$omp target 
>    a(11, 22) = 33
>    !$omp end target
> ```

In this particular example it looks like it's perhaps not working as expected and is maybe a missed case, the BoundsOp generation is still undergoing change AFAIK, quite a few patches recently. 

I agree, map(a) and map(a(11,22)) should both have bounds information generated for them, the former the full range of the array and the latter the sectioned boundaries. 


https://github.com/llvm/llvm-project/pull/67164


More information about the flang-commits mailing list