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

[llvmlistbot at llvm.org]

agozillon wrote:

I have updated the PR with an alternative method to the one described by @vzakhari currently (the new PR utilises members, but not addr_addr). As it seems from talking to @jeanPerier it might require a new operation addition for base_addr_addr (not adverse to trying that method though if we add the operation, just thought this idea was worth trying as well in the meantime).

The alternative method expands the mapping for box types/descriptors into additional implicit maps (currently only base_addr, but can add addendum as well, perhaps in a later patch, I just don't have an example that makes use of it inside of the target region to verify it'd work yet, so if anyone has one feel free to mention it) during the CodeGen process from HLFIR/FIR -> LLVM dialect, now instead of just converting the type into it's LLVM form it will also generate an implicit map for the base address from the currently lowered initial mapping which allows the runtime to later appropriately attach the pointer to the descriptor structure.   

The method allows us to avoid the need for knowing if a type is or is not a fortran allocatable at an OpenMP dialect level and for later lowering. 

I also moved the size/offset calculations required for sectioning to make use of the BoundsOp, I did have to make some minor changes to the shared DirectivesCommon.h lowering to always provide an extent in the BoundsOp as we need it to calculate the offset for now (perhaps I am overcomplicating the calculation though). It might be possible to only toggle the extent addition to always be on for OpenMP (or some other compromise if it's undesired behavior), so please do check the changes to this file in particular @razvanlupusoru @vzakhari @clementval, I am happy to split it out into a seperate PR, I left it in this for now to give context to the change. 

I think the most egregious change is adding the OpenMPPointerLikeModel to fir::BoxType's to allow there mapping, it might be possible to avoid this, but it'd complicate the CodeGen lowering for map_info. I can look into this if we do not like the addition of this trait to the BoxType's however, but generally are fine with the rest of the current method. 

I think the patch is possible to review it in it's current state to get the ball rolling on some feedback if this method seems reasonable, I believe @jeanPerier seemed to think it might be when I discussed it as an alternative with him. 

However, the patch stills needs the tests updated, and it appears the single-alloca.f90 test isn't working currently, but that seems HLFIR related, so could perhaps be non-specific to this PR (and if it is I'll remove the test for now and create a fix PR with it that can land after this in whatever form it lands). 

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