[PATCH] D114460: [fir] Add fir reduction builder

[Andrzej Warzynski via Phabricator via llvm-commits]

awarzynski added inline comments.


================
Comment at: flang/include/flang/Optimizer/Builder/Runtime/Reduction.h:7
+//
+//===----------------------------------------------------------------------===//
+
----------------



================
Comment at: flang/include/flang/Optimizer/Builder/Runtime/Reduction.h:21
+
+/// Generate call to all runtime routine.
+/// This calls the descriptor based runtime call implementation of the all
----------------
clementval wrote:
> kiranchandramohan wrote:
> > awarzynski wrote:
> > > rovka wrote:
> > > > clementval wrote:
> > > > > awarzynski wrote:
> > > > > > rovka wrote:
> > > > > > > Should we use backticks or something around function names? It reads really strange otherwise.
> > > > > > > Also, isn't this actually AllDim?
> > > > > > > Should we use backticks or something around function names? 
> > > > > > +1
> > > > > > 
> > > > > > Also, what is the difference between `genAllDescriptor` and `genAll`? Why do we need both?
> > > > > The comments are pretty clear on the differences. 
> > > > But to clarify: the runtime sometimes has different entry points for the same intrinsic, for special cases. In this case, IIUC, there's All and AllDim, both of which implement the ALL intrinsic. If you look in the standard, you'll see there's 2 variants: ALL(MASK) or ALL(MASK, DIM).
> > > > (...) to clarify (...)
> > > 
> > > Many thanks @rovka !
> > > 
> > > >  If you look in the standard (...)
> > > Ah, I see! In fact, I think that it would make a lot of sense to refer to the standard here and to use the notation from there as well (like in Diana's comment).
> > > 
> > > > The comments are pretty clear on the differences.
> > > 
> > > I disagree. There is `genAllDescriptor` and `genAll`, but there's no reference to any "descriptor" in the comments, arguments or the implementation. Also, both methods seem to "Generate call to all runtime routine", but one returns an `mlir::Value`, whereas the other is `void`. If both basically generate a call, then why are the interfaces completely different? I appreciate the this implementation may depend on the APIs in the runtime, but it still does not explain what this "descriptor" in `genAllDescriptor` is and what are the return values are.
> > For the descriptor version, the result is in an array for which a descriptor is needed. It is probably created by the runtime.
> > I disagree. There is genAllDescriptor and genAll, but there's no reference to any "descriptor" in the comments, arguments or the implementation. Also, both methods seem to "Generate call to all runtime routine", but one returns an mlir::Value, whereas the other is void. If both basically generate a call, then why are the interfaces completely different? I appreciate the this implementation may depend on the APIs in the runtime, but it still does not explain what this "descriptor" in genAllDescriptor is and what are the return values are.
> There is a reference to descriptor in the comment and there is a `result` argument which is the "descriptor". 
> 
> 
Thank you all for clarifying. This is starting to make sense. I still believe that the comments for these hooks should be improved and clarify the underlying logic. Please see my suggestion at the top of this file. WDYT? 


================
Comment at: flang/unittests/Optimizer/Builder/Runtime/ReductionTest.cpp:20
+  mlir::Value all = fir::runtime::genAll(*firBuilder, loc, undef, dim);
+  checkCallOp(all.getDefiningOp(), "_FortranAAll", 2);
+}
----------------
clementval wrote:
> awarzynski wrote:
> > Same suggestion in other places.
> Does this really help?
Yes. `_FortranAll` is somewhat self-explanatory. But `2` is a magic number without the comment.


================
Comment at: flang/unittests/Optimizer/Builder/Runtime/ReductionTest.cpp:25-26
+  auto loc = firBuilder->getUnknownLoc();
+  mlir::Type seqTy =
+      fir::SequenceType::get(fir::SequenceType::Shape(1, 10), i32Ty);
+  mlir::Value result = firBuilder->create<fir::UndefOp>(loc, seqTy);
----------------
clementval wrote:
> awarzynski wrote:
> > Move next to other "// Commonly used types" in `RuntimeCallTest`?
> Are you talking about `seqTy` or `result`? Not sure if the comment moved with the update. 
Both are re-defined multiple times. So is `undef`, `dim` and a few other. I'd keep only keep the bare minimum in every test that's unique to a particular case being tested. Reduced code-duplication, makes this file shorter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114460