[flang-commits] [flang] [openmp] [mlir] [Flang][OpenMP] Initial mapping of Fortran pointers and allocatables for target devices (PR #71766)

[via flang-commits]

================
@@ -0,0 +1,27 @@
+! Offloading test checking interaction of a
+! non-array allocatable with a target region
+! REQUIRES: flang, amdgcn-amd-amdhsa
+! UNSUPPORTED: nvptx64-nvidia-cuda
+! UNSUPPORTED: nvptx64-nvidia-cuda-LTO
+! UNSUPPORTED: aarch64-unknown-linux-gnu
+! UNSUPPORTED: aarch64-unknown-linux-gnu-LTO
+! UNSUPPORTED: x86_64-pc-linux-gnu
+! UNSUPPORTED: x86_64-pc-linux-gnu-LTO
+
+! RUN: %libomptarget-compile-fortran-run-and-check-generic
+! XFAIL: *
+program main
+    integer, allocatable :: test
+    allocate(test)
+    test = 10
+
+!$omp target map(tofrom:test)
+    test = 50
----------------
agozillon wrote:

This test will work quite happily using the old FIR flow, and fail on HLFIR, due to the utilisation of the HLFIR AssignOp which lowers to a runtime call that injects some bit of code that the instruction selector for AMD GPU cannot lower as it doesn't seem to support it: DYNAMIC_STACKALLOC (I think AMD GPUs do all stack allocation statically, I am not particularly knowledgeable on this segment of the compiler infrastructure though). I have unfortunately not been able to narrow it down to a specific line in the runtime library yet, but I imagine there's a number of areas as there's a lot of allocation occurring in the runtime library! And I imagine there is likely some other cases where HLFIR runtime library operations will cause a similar issue when compiling for AMD GPU. 

The only solution I have for this at the moment is to not emit the AssignOp and instead utilise the old FIR flow when compiling for an AMD device or perhaps whenever inside of an OpenMP target offload region. Not sure if that's a good or bad solution as I am not 100% clued up on what the end game is for the now deprecated FIR segments (I think the intent was to remove it all in Q1 next year, but I may be misremembering)? I am wondering if anyone else has any insight or suggestions on possible fixes for this. 

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