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

[Caroline Newcombe 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())
+                          : mlir::StringAttr{}) {
+      // Keep a view into the StringAttr storage; str() returns a temporary.
+      name = nameAttr.getValue();
----------------
cenewcombe wrote:

It looks like this could change the tags emitted in the default pipeline for OpenMP-private and `hlfir.associate` temporaries — both are classified `SourceKind::Allocate` without an allocate effect, and both carry `uniq_name`, so they'd now get a named allocated data tag where they previously got none. Is that intentional? Checking `isNewAllocationResult()` first and only consulting `uniq_name` when it's true would preserve current behavior; other cases could then be added deliberately.

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