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

[via flang-commits]

================
@@ -817,15 +817,28 @@ void AddAliasTagsPass::runOnAliasInterface(fir::FirAliasTagOpInterface op,
   } else if (enableLocalAllocs &&
              source.kind == fir::AliasAnalysis::SourceKind::Allocate) {
     std::optional<llvm::StringRef> name;
-    mlir::Operation *sourceOp =
-        llvm::cast<mlir::Value>(source.origin.u).getDefiningOp();
+    mlir::Value sourceVal = llvm::cast<mlir::Value>(source.origin.u);
+    mlir::Operation *sourceOp = sourceVal.getDefiningOp();
     bool unknownAllocOp = false;
     if (auto alloc = mlir::dyn_cast_or_null<fir::AllocaOp>(sourceOp))
       name = alloc.getUniqName();
     else if (auto alloc = mlir::dyn_cast_or_null<fir::AllocMemOp>(sourceOp))
       name = alloc.getUniqName();
-    else
+    else if (mlir::StringAttr nameAttr =
+                 sourceOp ? sourceOp->getAttrOfType<mlir::StringAttr>(
+                                fir::AllocaOp::getUniqNameAttrName())
----------------
jeanPerier wrote:

> source.origin.instantiationPoint

No because that could lead to an associating entity created by  ASSOCIATE to appear as  not aliasing with the selector variable.

All entities that are mapped to local allocations in the TBAA tree and that share the same allocation operation should be in the same TBAA branch, so we are using the name on the allocation operation to enforce that.

The build failure was just a bad last minute change to avoid hardcoding "uniq_name", and I fixed it by using `fir::getUniqNameAttrName`.

+1 for checking for `!empty`, done in the updated code.

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