[flang-commits] [flang] [NFC][flang] Introduce FortranObjectViewOpInterface. (PR #166841)

[via flang-commits]

================
@@ -938,8 +949,9 @@ def hlfir_EndAssociateOp : hlfir_Op<"end_associate", [MemoryEffects<[MemFree]>]>
   let hasVerifier = 1;
 }
 
-def hlfir_AsExprOp : hlfir_Op<"as_expr",
-    [DeclareOpInterfaceMethods<MemoryEffectsOpInterface>]> {
+def hlfir_AsExprOp
+    : hlfir_Op<"as_expr", [DeclareOpInterfaceMethods<MemoryEffectsOpInterface>,
+                           fir_FortranObjectViewOpInterface]> {
----------------
jeanPerier wrote:

Is this needed?

I do not think AsExpr is a view op, It result should be regarded as a value/tensor with no memory connection to the input.

When it has not been eliminated, it may end-up being implemented as a copy or as use the original storage if it is proven safe.

I think as_expr may have been given some handling in aliasing so that it could have an easier code generation.

I expect this was done so that hlfir.assign optimization would not optimize hlfir.asssign of hlfir.elemental using hlfir.as_expr in case the as_expr source overlaps with the LHS assuming that as_expr codegen could end up using the source.

But I feel the problem should be seen in the other direction, and it is up to the as_expr codegen to prove that it can safely replace the copy by its source.

If possible, I would prefer keeping the ad-hoc handling in FIR aliasing so that we can try to fix this instead of enshrining the assumption that as_expr result is based on its source in the operation definition.

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