[flang-commits] [flang] [flang] fix regression with optional after PR125059 (PR #125215)

[via flang-commits]

================
@@ -221,6 +221,25 @@ bool hlfir::Entity::mayHaveNonDefaultLowerBounds() const {
   return true;
 }
 
+mlir::Operation *traverseConverts(mlir::Operation *op) {
+  while (auto convert = llvm::dyn_cast_or_null<fir::ConvertOp>(op))
+    op = convert.getValue().getDefiningOp();
+  return op;
+}
+
+bool hlfir::Entity::mayBeOptional() const {
+  if (!isVariable())
+    return false;
+  // TODO: introduce a fir type to better identify optionals.
+  if (mlir::Operation *op = traverseConverts(getDefiningOp())) {
+    if (auto varIface = llvm::dyn_cast<fir::FortranVariableOpInterface>(op))
+      return varIface.isOptional();
+    return !llvm::isa<fir::AllocaOp, fir::AllocMemOp, fir::ReboxOp,
+                      fir::EmboxOp, fir::LoadOp>(op);
----------------
jeanPerier wrote:

Me, too, hence the comment about representing optional in the FIR type system.

> Maybe check if it is a function argument?

This would work for user OPTIONAL (assuming one is always able to walk back to the argument, which is a broad assumption), but not "lowering generated" optionals that are generated when passing deallocated pointers/allocatable. Hence it is safer to list what is known fir.box that are know to not be OPTIONAL because of their producers.

>From a correctness point of view, missing elements in the list does not matter, it will just trigger uglier code to be generated (the fir.if), and given scalar fir.box are pretty rare in lowering, it will not occur a lot.

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