search for: looplikeinterface

...;> In file included from >> /home/sourabh/mirror-upstream/mlir/include/mlir/Dialect/AffineOps/AffineOps.h:22:0, >> from >> /home/sourabh/mirror-upstream/mlir/lib/Analysis/AffineAnalysis.cpp:17: >> /home/sourabh/mirror-upstream/mlir/include/mlir/Transforms/LoopLikeInterface.h:22:10: >> fatal error: mlir/Transforms/LoopLikeInterface.h.inc: No such file or >> directory >> #include "mlir/Transforms/LoopLikeInterface.h.inc" >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Am I missing something? -- some pre-requis...

...obj.MLIRAnalysis.dir/AffineAnalysis.cpp.o In file included from /home/sourabh/mirror-upstream/mlir/include/mlir/Dialect/AffineOps/AffineOps.h:22:0, from /home/sourabh/mirror-upstream/mlir/lib/Analysis/AffineAnalysis.cpp:17: /home/sourabh/mirror-upstream/mlir/include/mlir/Transforms/LoopLikeInterface.h:22:10: fatal error: mlir/Transforms/LoopLikeInterface.h.inc: No such file or directory #include "mlir/Transforms/LoopLikeInterface.h.inc" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Am I missing something? -- some pre-requisites ? Thanks in anticipation! Sourabh. compilation...

...MLIR? It is not mentioned in the design as to how the various SSA values for various OpenMP clauses are passed around in OpenMP operations. D. Because of (A), (B) and (C), it would be beneficial to have an omp. parallel_do operation which has semantics similar to other loop structures (may not be LoopLikeInterface) in MLIR. To me, it looks like having OpenMP operations based on standard MLIR types and operations (scalars and memrefs mainly) is the right way to go. Why not have omp.parallel_do operation with AffineMap based bounds, so as to decouple it from Value/Type similar to affine.for? 1. With the curr...

...structs and clauses > which was shared as mails to flang-dev and the RFC. As we make progress and > before implementation, we will share further details. > > it would be beneficial to have an omp.parallel_do operation which has > semantics similar to other loop structures (may not be LoopLikeInterface) > in MLIR. > > I am not against adding parallel_do if it can help with transformations or > reduce the complexity of lowering. Please share the details in discourse as > a reply to the RFC or a separate thread. > > it looks like having OpenMP operations based on standard MLIR...

...as shared as mails to flang-dev and the RFC. As we make progress and >>> before implementation, we will share further details. >>> >>> it would be beneficial to have an omp.parallel_do operation which has >>> semantics similar to other loop structures (may not be LoopLikeInterface) >>> in MLIR. >>> >>> I am not against adding parallel_do if it can help with transformations >>> or reduce the complexity of lowering. Please share the details in discourse >>> as a reply to the RFC or a separate thread. >>> >>> it loo...

...and the RFC. As we make >>>>> progress and before implementation, we will share further details. >>>>> >>>>> it would be beneficial to have an omp.parallel_do operation which has >>>>> semantics similar to other loop structures (may not be LoopLikeInterface) >>>>> in MLIR. >>>>> >>>>> I am not against adding parallel_do if it can help with >>>>> transformations or reduce the complexity of lowering. Please share the >>>>> details in discourse as a reply to the RFC or a separate...

...gt; > SSA values for various OpenMP clauses are passed around in OpenMP > > operations. > > > > D. Because of (A), (B) and (C), it would be beneficial to have an omp. > > parallel_do operation which has semantics similar to other loop > structures > > (may not be LoopLikeInterface) in MLIR. To me, it looks like having > OpenMP > > operations based on standard MLIR types and operations (scalars and > memrefs > > mainly) is the right way to go. > > > > Why not have omp.parallel_do operation with AffineMap based bounds, so as > > to decouple...