[WIP][MLIR][Flang] WIP additional mapping support

[agozillon]

NOTE: this is a furthering of #217 based on Sergio's rebased of the PR 217 in #224. Starting fresh to maintain the commit history of PR 217.

This patch allows the current milestone 1 example we have to be extended to something like the below:

module test_0
        implicit none
        integer :: decltar_v = 5
    !$omp declare target link(decltar_v)
end module test_0
program main  
        integer :: hostArray(10), errors = 0  
        do i = 1, 10    
                hostArray(i) = 0  
        end do  
        call writeIndex(hostArray, 10)
        do i = 1, 10    
                if ( hostArray(i) /= i ) then
                        errors = errors + 1    
                end if  
        end do  
        if ( errors /= 0 ) then
                stop 1  
        end if
        print*, "======= FORTRAN Test passed! ======="
!       stop 0
end program main
subroutine writeIndex(int_array, array_length)
        use test_0
        integer :: int_array(*)
        integer :: array_length  
        integer :: new_len
        integer :: v = 5 ! global, when given value like this
        ! v = 5 ! local, when given value like this 
!$omp target map(tofrom:new_len) map(tofrom:decltar_v)
        new_len = decltar_v + v 
!$omp end target
        print*, new_len
        do index_ = 1, new_len 
                int_array(index_) = index_  
        end do
end subroutine writeIndex

This is by no means full support for map for either implicit, explicit or declare target, but it will hopefully allow a bit more support for them when applied.

I intend to look into the declare target component for the time being, however, I will come back to the other argument types if no one gets around to them before I finish the declare target work! If someone wishes to build on or get some ideas of where to start with the map clauses to further increase support I can give a breakdown. However, if building on this patch, it likely needs the following extensions to start:

1. An MLIR attribute for capture types on map clauses, in addition to the from/to/fromto, e.g. capture bythis, byref, byval
2. A lowering to this capture type from the PFT by the frontend during Target Op lowering, which needs to create a mapping from the type and method of it's capture to the capture type, similarly to the way Clang currently does it
3. An extension to the current optimsation pass (or better yet, move this pass to the PFT lowering so it's not a pass anymore and we have access to all the PFT details) to give all the implicit captures an appropriate capture type as they are hoisted into the map
4. Further extension of the Target Op Map PFT lowering to support more maptypes, a lot of the maptypes generated are very basic and will cause runtime errors at the moment, as maptypes are a conglomerate of a bunch of bitshifts based on the type of the variable, it's capture and how
5. Extension or some variation of the castInput function (perhaps a rename as well) to mimic GenerateOpenMPCapturedVars from Clang which generates additional operations for inputs based on capture type (operations for how to appropriately access things byval/byref etc.), an extension to the additional version for host which I have currently called createAlteredByCaptureMap which generates some additional operations when passing input to kernels via the map.

This is just some possible things that need done if using this patch as a base, but will generally give an idea of the extent of things that need doing for implicit/explicit map variables. And of course, anyone picking this up can do as they wish/best see fit these are suggestions from what I found doing this patch!

The following two Clang functions may be of interest when doing the above (although, not exhaustive, anywhere where the maptype enum or capture enum are referenced is of interest, in particular one really large map related function):

• GenerateOpenMPCapturedVars (whole function)
• emitOutlinedFunctionPrologue (primarily the end of the function dealing with input)

There's essentially a lot of special case operation generation for argument passing and accessing based on capture type inside of Clang.

There's a lot of TODO/FIXME's all over the place at the moment and some dump/outs, so please be aware if you directly apply the entire patch.

The patch also looks a little beefier than it should be as it applies some other phab patches I have to work, namely D149162 and D149368, the former is now upstreamed, so updating ATD on main will shrink the diff a little.

[github-actions]

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:

git-clang-format --diff 911367e4fd735f70ffcc3ff8c8540bff92d47068 90e1b5b82e080560269c98b052b597577b98593f -- flang/include/flang/Lower/OpenMP.h flang/lib/Frontend/FrontendActions.cpp flang/lib/Lower/Bridge.cpp flang/lib/Lower/ConvertVariable.cpp flang/lib/Lower/OpenMP.cpp flang/lib/Optimizer/Builder/FIRBuilder.cpp flang/lib/Optimizer/CodeGen/CodeGen.cpp llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp mlir/include/mlir/Target/LLVMIR/ModuleTranslation.h mlir/lib/Conversion/OpenMPToLLVM/OpenMPToLLVM.cpp mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp mlir/lib/Target/LLVMIR/ModuleTranslation.cpp

View the diff from clang-format here.

diff --git a/mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp b/mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
index e54d5f0380c6..ec6bac3ff860 100644
--- a/mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ b/mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -2925,7 +2925,7 @@ convertOmpTarget(Operation &opInst, llvm::IRBuilderBase &builder,
   }
 
   ompBuilder->CurrentTargetInfo.emplace();
-  
+
   builder.restoreIP(ompBuilder->createTarget(
       ompLoc, targetOp.isTargetSPMDLoop(), allocaIP, builder.saveIP(),
       entryInfo, kernelInput, genMapInfoCB, bodyCB, argAccessorCB));

[agozillon]

Now superseded by: #249

Which is the allocatables segment of this PR with the implicit handling stripped out to utilise the new IFA approach for implicits.