[flang-commits] [PATCH] D139020: [flang] hlfir.associate and hlfir.end_associate codegen

[Slava Zakharin via Phabricator via flang-commits]

vzakhari added inline comments.


================
Comment at: flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp:65
+static mlir::Value getBufferizedExprStorage(mlir::Value bufferizedExpr) {
+  auto tupleType = bufferizedExpr.getType().dyn_cast<mlir::TupleType>();
+  if (!tupleType)
----------------
It looks like there is an implicit assumption that there are no `mlir::TupleType` operands in the operations that are transformed by this pass before this pass launches OR if such operands are present and they match the `tuple<variable address, cleanupFlag>` pattern, then they indeed represent the bufferization package.  Am I reading it right?  It seems somewhat subtle to me, and I would rather use a distinct FIR type to represent the package so that values of this type have a well-defined meaning.  I guess it should be okay as-is if we do not expect `mlir::TupleType` operands ever appear elsewhere.


================
Comment at: flang/lib/Optimizer/HLFIR/Transforms/BufferizeHLFIR.cpp:121
             *lhsExv.getCharBox(), *rhsExv.getCharBox());
+    /// Ensure the memory type is the same as the result type.
+    mlir::Type addrType = fir::ReferenceType::get(
----------------
nit: unnecessary doxygen-style comment '///'.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139020/new/

https://reviews.llvm.org/D139020