[Mlir-commits] [mlir] [MLIR][SCF] Fix LoopPeelOp documentation (NFC) (PR #113179)

[Hugo Trachino]

================
@@ -158,12 +158,12 @@ def LoopPeelOp : Op<Transform_Dialect, "loop.peel",
      This operation ignores non-scf::ForOp ops and drops them in the return.
 
      When `peelFront` is true, this operation returns two scf::ForOp Ops, the
-     first scf::ForOp corresponds to the first iteration of the loop which can
-     be canonicalized away in the following optimization. The second loop Op
-     contains the remaining iteration, and the new lower bound is the original
-     lower bound plus the number of steps.
+     first scf::ForOp corresponds to the target loop, whose lower bound has
+     been updated to the original lower bound plus the step. The second result
+     is the first iteration of the loop which can be canonicalized away in the
+     following optimization.
----------------
nujaa wrote:

Hi, I can understand my suggestion is unclear i'll try to come up with something better. What is originally wrong is the order of the results of the transformOp when peel_front is true.
The transform op returns 2 forops like :
%iteration1_to_n, %iteration_0= transform.loop.peel %1 {peel_front = true} : (!transform.op<"scf.for">) -> (!transform.op<"scf.for">, !transform.op<"scf.for">)
Whereas the original description suggested %iteration0, %iteration_1_to_n

New suggestion : 
When `peelFront` is true, this operation returns two scf::ForOp Ops, the
     first scf::ForOp executes all iterations of the target loop but the first one. The second result is another scf::ForOp corresponding to the first iteration of the loop which can
     be canonicalized away in the following optimizations. Although not straightforward, The results are in this order to keep the `[mainloop, remainder]`  format of PeelOp general case.

https://github.com/llvm/llvm-project/pull/113179