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

Joel E. Denny via flang-commits flang-commits at lists.llvm.org
Wed May 1 16:26:13 PDT 2024


================
@@ -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))
----------------
jdenny-ornl wrote:

> I was due for an example of box, passed by value:
> 
> ```
> subroutine test(p)
>   real [,TARGET] :: p(:)
> end subroutine test
> ```
> 
> ```
> func.func @_QPtest(%arg0: !fir.box<!fir.array<?xf32>> {fir.bindc_name = "p", fir.target})
> ```
> 
> I am not the expert here (that would be @jeanPerier ), but the rationale was to communicate in FIR that the callee does not modify the box and that therefore, to the caller, the box is a shallow constant. They do end up being passed by reference in codegen but show as values in FIR.

Thanks for the example.  That helps.  However, 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.  If indeed it never makes sense to do that, then it seems it wouldn't matter whether we distinguish this box from its content as only the content is a candidate for alias analysis.

> I wonder if it will be more clear to only keep the first four source kinds and move `Direct` into the attributes. We are looking for the source entity here, so the source kind should represent this source entity. Whatever happens during the use-def chain walk should not affect the kind of the source entity that we end up finding. The `Direct`, in this case, would mean that the reference value passed to `getSource` is a result of one or more dereferences of the original source. I just find it easier to think about it this way, though, you may know cases where it can complicate the implementation.

Might make sense.  However, I've been assuming that, once you extract an address from a box, then you no longer have a global, dummy arg, local, or whatever the box is, so I thought it was ok to just call it a `Direct`.  Maybe that's wrong?  On that point, does anyone object to this patch's changes to `flang/test/Transforms/tbaa2.fir`?  There, this patch causes the address extracted from a dummy argument allocatable to be labeled `SourceKind::Direct` and not `SourceKind::Argument`.  Is that problematic?

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


More information about the flang-commits mailing list