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

[via flang-commits]

================
@@ -136,6 +136,9 @@ static constexpr llvm::StringRef getAccessGroupsAttrName() {
   return "access_groups";
 }
 
+/// Attribute to mark coarray Fortran entities with the CORANK attribute.
+constexpr llvm::StringRef getCorankAttrName() { return "fir.corank"; }
----------------
jeanPerier wrote:

I would not follow the attribute path. In my experience, this seems great at first and leads to a lot of trouble if the design is to find it back on defining operation. Any passes that does IR motion is at risk of breaking the IR without knowing when trying to outline IR/promote SSA value to block arguments.

It is also easy to lose attributes set on operation for which these attributes are not defined in the operation itself (e.g., canonicalization patterns optimizing a fir.box_addr + fir.embox + fir.box_addr to the first fir.box_addr will lose any attributes set on the second fir.box_addr). And we do not want canonicalization patterns to become overburdened by having to deal with this.

To me, you likely need to at least had a new optional corank field to BoxType and ClassType accessible via BaseBoxType too.
This would mean that you "lose" the information that something is a coarray as soon as it is manipulated by raw reference, unless it is pushed into the raw pointer type system too (why not).
It is unclear to me how much you need/want to manipulate coarray in context where it matters they are coarrays without manipulating them via descriptor.

Another alternative is to have a wrapping type fir.coarray<> around all the fir.box/...., fir.ref so that the type remains a bit orthogonal, but this will likely require you some changes in lowering/FIR too to understand and work with this new wrapping type where it matters. If we however were to track coarrays at runtime via some handle that is not a descriptor/raw address, that is the solution that would make the most sense.

You can probably punt a bit more on the topic by adding the corank as an explicit/required attribute to the operations that need them to avoid introducing getDefinigOp lookups.


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