[flang-commits] [flang] [fir][AddAliasTags] allow usage of AddAliasTag pass after FirToMemref (PR #219493)

Tom Eccles via flang-commits flang-commits at lists.llvm.org
Wed Sep 2 06:19:56 PDT 2026


================
@@ -837,7 +846,6 @@ void AddAliasTagsPass::runOnAliasInterface(fir::FirAliasTagOpInterface op,
     // which then incorrectly eliminates the copy stores.
     bool isValueDummyCopy = false;
     if (!unknownAllocOp) {
-      mlir::Value sourceVal = llvm::cast<mlir::Value>(source.origin.u);
       if (fir::DeclareOp declareOp = getDeclareOp(sourceVal)) {
----------------
tblah wrote:

Please address in a follow up patch, apologies for my lateness to this review, I had a few days off work. This isn't too critical because, as you mentioned, fir-to-memref isn't fully supported with AddAliasTags anyway.

Codex pointed out that there's a problem with how AddAliasTags handles 
```
subroutine passbyvalue(x)
  integer, value :: x
end subroutine
```

Flang initially creates a local `fir.alloca`, copy-in `fir.store`, and `fir.declare`. FIR-to-memref then replaces the allocation with:

```
%alloca = memref.alloca() : memref<i32>
%ref = fir.convert %alloca : (memref<i32>) -> !fir.ref<i32>
```

`getDeclareOp` can't currently look through the `fir.convert` uses to find the declare so it doesn't find the `declareOp` and so can't find the VALUE attribute.

The lack of this results in the `fir.store` for the VALUE copy and subsequent loads getting different tags. The store is incorrectly in the local allocation subtree but the load (which is to the declare op not the convert) is correctly a dummy argument.

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


More information about the flang-commits mailing list