[all-commits] [llvm/llvm-project] afb05c: [Flang][MLIR][OpenMP] Create a deferred declare ta...

[agozillon via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: afb05cd6469215232bd83e7cfbe59d2e1852567f
      https://github.com/llvm/llvm-project/commit/afb05cd6469215232bd83e7cfbe59d2e1852567f
  Author: agozillon <Andrew.Gozillon at amd.com>
  Date:   2024-03-05 (Tue, 05 Mar 2024)

  Changed paths:
    A flang/docs/OpenMP-declare-target.md
    M flang/docs/index.md
    M flang/include/flang/Lower/OpenMP.h
    M flang/lib/Lower/Bridge.cpp
    M flang/lib/Lower/OpenMP/OpenMP.cpp
    M flang/lib/Lower/OpenMP/Utils.h
    A flang/test/Lower/OpenMP/declare-target-deferred-marking.f90

  Log Message:
  -----------
  [Flang][MLIR][OpenMP] Create a deferred declare target marking process for Bridge.cpp (#78502)

This patch seeks to create a process that happens on module finalization
for OpenMP, in which a list of operations that had declare target
directives applied to them and were not generated at the time of
processing the original declare target directive are re-checked to apply
the appropriate declare target semantics.

This works by maintaining a vector of declare target related data inside
of the FIR converter, in this case the symbol and the two relevant
unsigned integers representing the enumerators. This vector is added to
via a new function called from Bridge.cpp, insertDeferredDeclareTargets,
which happens prior to the processing of the directive (similarly to
getDeclareTargetFunctionDevice currently for requires), it effectively
checks if the Operation the declare target directive is applied to
currently exists, if it doesn't it appends to the vector. This is a
seperate function to the processing of the declare target via the
overloaded genOMP as we unfortunately do not have access to the list
without passing it through every call, as the AbstractConverter we pass
will not allow access to it (I've seen no other cases of casting it to a
FirConverter, so I opted to not do that).

The list is then processed at the end of the module in the
finalizeOpenMPLowering function in Bridge by calling a new function
markDelayedDeclareTargetFunctions which marks the latently generated
operations. In certain cases, some still will not be generated, e.g. if
an interface is defined, marked as declare target, but has no definition
or usage in the module then it will not be emitted to the module, so due
to these cases we must silently ignore when an operation has not been
found via it's symbol.

The main use-case for this (although, I imagine there is others) is for
processing interfaces that have been declared in a module with a declare
target directive but do not have their implementation defined in the
same module. For example, inside of a seperate C++ module that will be
linked in. In cases where the interface is called inside of a target
region it'll be marked as used on device appropriately (although,
realistically a user should explicitly mark it to match the
corresponding definition), however, in cases where it's used in a
non-clear manner through something like a function pointer passed to an
external call we require this explicit marking, which this patch adds
support for (currently will cause the compiler to crash).

This patch also adds documentation on the declare target process and 
mechanisms within the compiler currently.



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