[PATCH] D74708: [MLIR][Ploops] Add custom builders from ParallelOp and ReduceOp.

Mehdi AMINI via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 19 08:33:07 PST 2020


mehdi_amini added inline comments.


================
Comment at: mlir/include/mlir/Dialect/LoopOps/LoopOps.td:188
+              "ValueRange lowerBounds, ValueRange upperBounds, "
+              "ValueRange steps, ArrayRef<Type> resultTypes">
   ];
----------------
herhut wrote:
> pifon2a wrote:
> > mehdi_amini wrote:
> > > Isn't a loop always supposed to capture as operands the same types as the returned values? If so then why do we have a builder with `resultTypes`? I'd expect these to be inferred from the captured operands?
> > > 
> > > It is a problem with the current reduce, which does not model this, but that's a bug to fix right? And so adding a builder around the incorrect design does not seem right to me.
> > Ploops don't really capture any operands from which we can infer result types. The result types correspond to the ReduceOps in the body of the ploop.
> We have not added neutral values that can be used as initial values to parallel loops, yet, and I am not sure whether they should be mandatory. Having neutral values unlocks some additional reduction schemes but they are not always necessary. If we make them optional, we will need to provide return types to support that. 
> If we make them mandatory, we can adapt the builders and their use sites.
I thought we discussed this and it would be added?
There is no guarantee that a loop would be executed once: as such it should take an input value for all returned to support this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74708





More information about the llvm-commits mailing list