[all-commits] [llvm/llvm-project] f4cf93: [Flang][OpenMP] Align map clause generation and f...

[agozillon via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f4cf93fb509c53771d61a973f27be9b1a90dee0a
      https://github.com/llvm/llvm-project/commit/f4cf93fb509c53771d61a973f27be9b1a90dee0a
  Author: agozillon <Andrew.Gozillon at amd.com>
  Date:   2024-08-23 (Fri, 23 Aug 2024)

  Changed paths:
    M flang/include/flang/Optimizer/OpenMP/Passes.td
    M flang/include/flang/Tools/CLOptions.inc
    M flang/lib/Lower/OpenMP/ClauseProcessor.cpp
    M flang/lib/Lower/OpenMP/ClauseProcessor.h
    M flang/lib/Lower/OpenMP/OpenMP.cpp
    M flang/lib/Optimizer/OpenMP/MapInfoFinalization.cpp
    M flang/test/Lower/OpenMP/array-bounds.f90
    M flang/test/Lower/OpenMP/common-block-map.f90
    M flang/test/Lower/OpenMP/derived-type-map.f90
    M flang/test/Lower/OpenMP/target.f90
    A offload/test/offloading/fortran/local-descriptor-map-regress.f90

  Log Message:
  -----------
  [Flang][OpenMP] Align  map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types (#97855)

This PR aims to unify the map argument generation behavior across both
the implicit capture (captured in a target region) and the explicit
capture (process map), currently the varPtr field of the MapInfo for the
same variable will be different depending on how it's captured. This PR
tries to align that across the generations of MapInfoOp in the OpenMP
lowering.

Currently, I have opted to utilise the rawInput (input memref to a HLFIR
DeclareInfoOp) as opposed to the addr field which includes more
information. The side affect of this is that we have to deal with
BoxTypes less often, which will result in simpler maps in these cases.
The negative side affect of this is that we don't have access to the
bounds information through the resulting value, however, I believe the
bounds information we require in our case is still appropriately stored
in the map bounds, and this seems to be the case from testing so far.

The other fix is for cases where we end up with a BoxType argument into
a function (certain assumed shape and sizes cases do this) that has no
fir.ref wrapping it. As we need the Box to be a reference type to
actually utilise the operation to access the base address stored inside
and create the correct mappings we currently generate an intermediate
allocation in these cases, and then store into it, and utilise this as
the map argument, as opposed to the original.

However, as we were not sharing the same intermediate allocation across
all of the maps for a variable, this resulted in errors in certain cases
when detatching/attatching the data e.g. via enter and exit. This PR
adjusts this for cases

Currently we only maintain tracking of all intermediate allocations for
the current function scope, as opposed to module. Primarily as the only
case I am aware of that this is required is in cases where we pass
certain types of arguments to functions (so I opted to minimize the
overhead of the pass for now). It could likely be extended to module
scope if required if we find other cases where it's applicable and
causing issues.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications