[flang-commits] [PATCH] D150455: [flang][hlfir] Implement the scheduling part of hlfir.forall codegen

Tue May 16 09:03:36 PDT 2023

vzakhari accepted this revision.
vzakhari added a comment.

Thank you for the update, Jean!

================
Comment at: flang/include/flang/Optimizer/HLFIR/HLFIROps.td:173
 def hlfir_DesignateOp : hlfir_Op<"designate", [AttrSizedOperandSegments,
-    DeclareOpInterfaceMethods<fir_FortranVariableOpInterface>]> {
+    DeclareOpInterfaceMethods<fir_FortranVariableOpInterface>, NoMemoryEffect]> {
   let summary = "Designate a Fortran variable";
----------------
jeanPerier wrote:
> vzakhari wrote:
> > Is it true for dynamically sized derived types that the `DesignateOp` does not have memory effects?  Does the call generated during `FieldIndexOp` code-gen access any memory?
> I do not have a good answer here because it is still not 100% clear to me how this will be dealt with. The runtime approach lays out dynamically sized component in "automatic components" that are special allocatable components.
> 
> So if this is not abstracted in FIR/HLFIR, the memory effects will happen via a fir.load of the addresses component fir.box (like for allocatable components).
> 
> The FieldIndexOp codegen was forcasting an approach where the data would be directly laid out in the structure with no descriptor indirection.
> 
> Right now, it is safe to say it has no memory effects (it may however crash if the incoming fir.box is an absent optional, that is why I did not add Pure: it is not speculatable with optional input for now).
> 
> We will likely need to revisit this depending on how PDTs are implemented (we can implement the MemoryEffectInterface to have finer control about when an operation has side effects and when it does not based on the arguments).
Thank you for the explanation!  I am okay with having `NoMemoryEffect` for the time being.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150455