[llvm] [OpenMP][Flang][Clang][Offload] Prevent shadow pointer write-back to null host pointers (PR #197106)

[Abhinav Gaba via llvm-commits]

================
@@ -0,0 +1,70 @@
+! OpenMP offloading regression test that checks we do not write-back data
+! in cases where the host descriptor and data have been deallocated during the
+! time the data was on device. This predominantly crops up as an issue in the
+! UMT benchmark.
+!
+! The key component of this test is that we map back elements of an array inside
+! of a derived type, and then want to deallocate them on the host, but subsequent
+! maps back from device of other elements re-allocate/re-map back the old data we
+! just went deallocated on host.
+! REQUIRES: flang, amdgpu
+
+! RUN: %libomptarget-compile-fortran-run-and-check-generic
+program prog
+   implicit none
+
+   type :: dtype_a
+      real(8),      pointer, contiguous :: array2d(:,:) => null()
+      integer :: scalar_int
+   end type dtype_a
+
+   type :: dtype_b
+      type(dtype_a),      pointer     :: array1d(:) => null()
+   end type dtype_b
+
+   integer :: i, j = 4
+   type(dtype_b), pointer :: alloca_dtype => null()
+
+   allocate(alloca_dtype)
+   allocate(alloca_dtype%array1d(j))
+   do i = 1, j
+      allocate(alloca_dtype%array1d(i)%array2d(10,10))
+   enddo
+
+    !$omp target enter data map(to:alloca_dtype)
+    !$omp target enter data map(always,to:alloca_dtype%array1d)
+   do i = 1, j
+    !$omp target enter data map(always,to:alloca_dtype%array1d(i)%array2d)
+   end do
+
+    ! Check everything is all still associated as we'd expect.
+    do i = 1, j
+        if (associated(alloca_dtype%array1d(i)%array2d)) then
+          write (*,*) "iteration", i, "is associated"
+       endif
+    enddo
+
+! In this loop, we map back scalar_int and array2d of the corresponding
+! array1d iteration, however, subsequent map backs of scalar_int, will
+! re-allocate and re-associate the previous iteration of array2d.
+    do i = 1, j
+!$omp target update from(alloca_dtype%array1d(i)%scalar_int)
+!$omp target update from(alloca_dtype%array1d(i)%array2d)
----------------
abhinavgaba wrote:

It's a test-case error. This line should have been:

```f90
!$omp target exit data map(delete, from: alloca_dtype%array1d(i)%array2d)

```

With that, the test works as expected with flang on x86_64:

```
❯ flang-new -O0 -fopenmp -fopenmp-targets=x86_64 map_struct_with_dv_then_deallocate.f90 -fopenmp-version=61 && ./a.out
warning: The specification for OpenMP version 61 is still under development; the syntax and semantics of new features may be subject to change
warning: The specification for OpenMP version 61 is still under development; the syntax and semantics of new features may be subject to change
warning: The specification for OpenMP version 61 is still under development; the syntax and semantics of new features may be subject to change
 iteration 1 is associated
 iteration 2 is associated
 iteration 3 is associated
 iteration 4 is associated
 iteration 1 is unassociated
 iteration 2 is unassociated
 iteration 3 is unassociated
 iteration 4 is unassociated
```

An attached pointer stays attached for its lifetime on device, and if a pointer is attached on device, it's illegal to nullify/deallocate it on host. OpenMP 6.1 will add support for force-re-attachment using `attach(always)`, but detaching is not supported in 6.1 either.

As per OpenMP 6.0, it is not legal to even re-associate an attached-pointer to a different (non-null) target:
```
OpenMP 6.0 page 288
• If a list item of a map clause is an allocatable variable or is the subobject of an allocatable variable, the original list item must not be allocated, deallocated or reshaped while the corresponding list item has allocated storage.
• A pointer that has a corresponding pointer that is an attached pointer and is associated with a given pointer target must not become associated with a different pointer target for the duration of the lifetime of the list item to which the corresponding pointer is attached in the device data environment
```

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