[flang-commits] [flang] [Flang][MIF] Adding support of intrinsics with coarray argument (PR #192944)

[Jean-Didier PAILLEUX via flang-commits]

JDPailleux wrote:

> Thanks for the update, that is an interesting approach I did not expect. I can see why you can justify making fir.coarray a value type (as if it were a value whose SSA register is spit over all the different images), but I feel that in practice the coarray abstraction relates more to memory and how you access it than SSA values, so I would rather have this be a memory type like fir.box/class/ref...., or an attribute of such type that stores the corank. In general I think I would advocate against making it a new optional "stage" of the type nesting (regardless of whether it would wrap a FIR memory type or a FIR value type . My return of experience with having done that with ALLOCATALE/POINTER inside fir.box (by adding fir.ptr/fir.heap indirection before the value type) is that this brings more complexity ambiguity than having a fir.box_ptr of attribute.
> 
> In any case, I think this is a design choice that deserve a small design write ups with usages/motivation/alternative to select the solution. I am not requesting you to introduce the new type here, I am fine with having the corank attribute set on the operation whose codegen requires it instead of trying to retrieve it from fir.box_addr and al. for now. My main grudge was that codegen that retrieve things via getDefiningOp tends to break in the long run.

I proposed this approach because, for an “array,” we already have the `fir.array` type, so why not a `fir.coarray` type for a coarray which make more sens in my opinion. Identifying a variable as a coarray (and therefore knowing its corank) becomes very simple, just like indicating to the various MIF operations that expect a coarray as an argument.

I understand your point that, in practice, the coarray abstraction relates more to memory, but I would say it has more to do with how it uses a variable and, therefore, its accessibility across all images. If no image selector is provided for a variable, doing `A = B + C` or a `print *, A` results in the classic behavior of a variable (i.e., fir.ref, fir.box, or nothing at all). And retrieving or sending a value from one image to another just requires using PUT and GET, but I might be wrong.

Otherwise, I can provide a document as you mentioned if necessary to justify my choice.
But if that is not suitable in this context, I’ll go back to my initial idea of the `fir.corank` attribute, but with `fir.coarray<corank>`, or I’ll adapt `fir.coarray` so that it becomes a `fir::CoarrayValue`something, but I’m afraid we’ll lose the distinction between ADDR and VALUE for a coarray (though I haven’t looked into it yet). 

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