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

[llvmlistbot at llvm.org]

agozillon wrote:

> > I think it will be good to write down this as an RFC. This is specifically for two reasons:
> > 
> > 1. We are using Fortran-specific information in the dialect and its translation.
> > 2. We have decided to use the Flang descriptor for some purposes and the MapInfo/Bounds operation for other purposes. It will be good to clarify that and also decide what should be the best source for a particular kind of information.
> 
> I'll try to elaborate a bit more on this soon, after I update the PR. And I'd be happy to create an RFC, but perhaps it's worth waiting on a little bit more reviewer input after I update the PR with more details (on the chance reviewers might be able to indicate a better choice in certain areas that I hadn't came across)? If you don't think that's worthwhile though or it's more worthwhile to have two avenues of feedback (PR + RFC) I'm more than happy to open up the RFC just now rather than waiting a little bit!
> 
> However, for 2) it's quite possible to use the BoundsOp for a lot of the calculations as they directly access the descriptor fields, the only issue I've found is that there is no element type size field for the BoundsOp (as far as I'm aware at least). You can use getStride() (when getStrideInBytes is true, which is the case currently for allocatables), however, I opted to not do so as I imagine the value returned will change when a user specifies a stride, although, @razvanlupusoru can likely clarify if it would!
> 
> So, rather than having a mismatch of accessing the descriptor field directly in one case and using the bounds in all other cases I opted to just directly access the descriptor in all cases, however, I'd be happy to change the calculation to use BoundsOp where feasible if that seems more reasonable? I'm unsure if adding an ElementTypeSize field to bounds is a reasonable sounding change but that could also be an option to fully utilise just the BoundsOp for the calculation

I also realised that while we could use the BoundsOp like this for cases where the allocatable is an array, we can't if it's a non-array allocatable as they aren't generated. Although, no complex calculations are required for it in these cases, but I believe we do still access the descriptor directly for the pointer (can't avoid this using the BoundsOp in any case) and the type size of the data contained in the descriptor. 

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