[flang-commits] [flang] [flang] AliasAnalysis: distinguish addr of arg vs. addr in arg (PR #87723)

[Renaud Kauffmann via flang-commits]

================
@@ -399,19 +404,30 @@ AliasAnalysis::Source AliasAnalysis::getSource(mlir::Value v) {
   if (!defOp && type == SourceKind::Unknown)
     // Check if the memory source is coming through a dummy argument.
     if (isDummyArgument(v)) {
-      type = SourceKind::Argument;
       ty = v.getType();
       if (fir::valueHasFirAttribute(v, fir::getTargetAttrName()))
         attributes.set(Attribute::Target);
-
       if (Source::isPointerReference(ty))
         attributes.set(Attribute::Pointer);
+      if (followBoxAddr && fir::isa_ref_type(ty))
----------------
Renaud-K wrote:

> I'm struggling with the idea of performing a FIR alias analysis on something (the box in this example) that FIR represents as a value not an address

Right, we could do some ground work before adding further enhancements to enforce that we start from a memory reference always. I wanted to check with @jeanPerier before we do that, in case he might need to make adjustments in lowering. 

Let's note that when we are at the LLVM level, the box is an address and it becomes a legitimate question to ask. I will have to dig some to see how we handle this case.

What I would be struggling with is that following the address of a POINTER takes you to a SourceKind::Direct but following the address of a TARGET takes you to a SourceKind::Argument.

> I wonder if it will be more clear to only keep the first four source kinds and move Direct into the attributes

Yes, then we would get consistent source kinds for target and pointers and we should get the same attribute, that I would hope we would have renamed to something other than "Direct" then. That would require some buy-in from @tblah as it would require changes in `runOnAliasInterface` though it should not cause any change in the results.


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