[flang-commits] [flang] [flang][hlfir] Resolve shape_of users when bufferizing eval_in_mem (PR #201214)

[via flang-commits]

================
@@ -638,16 +638,26 @@ tryUsingAssignLhsDirectly(hlfir::EvaluateInMemoryOp evalInMem,
   mlir::Location loc = evalInMem.getLoc();
   hlfir::DestroyOp destroy;
   hlfir::AssignOp assign;
-  for (auto user : llvm::enumerate(evalInMem->getUsers())) {
-    if (user.index() > 2)
+  // A hlfir.shape_of of the result only needs the shape, which the
+  // eval_in_mem already carries as an operand, so it can be redirected to that
+  // operand and does not prevent the in-place rewrite below. Any other user
+  // would dangle when the eval_in_mem is erased, so bail out on it.
+  llvm::SmallVector<hlfir::ShapeOfOp> shapeOfs;
+  for (mlir::Operation *user : evalInMem->getUsers()) {
+    if (auto op = mlir::dyn_cast<hlfir::AssignOp>(user))
+      assign = op;
+    else if (auto op = mlir::dyn_cast<hlfir::DestroyOp>(user))
+      destroy = op;
----------------
jeanPerier wrote:

There could still be weird bugs if the expression is used in several hlfir.assign and destroys.

Several hlfir.assign use is not OK and should be prevented with something like:
```
if (auto op = mlir::dyn_cast<hlfir::AssignOp>(user)) {
  if (assign)
    return mlir::failure
}
```

Several destroys could be dealt with (all of them should just be deleted) so they could be collected in a vector, but since it is quite unlikely (but not impossible), I am also fine if you restrict it to one destroy.

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