[Openmp-commits] [flang] [llvm] [mlir] [openmp] [MLIR][OpenMP] Add omp.fuse operation (PR #168898)

[Ferran Toda via Openmp-commits]

================
@@ -3435,6 +3435,20 @@ void NewCliOp::getAsmResultNames(OpAsmSetValueNameFn setNameFn) {
             .Case([&](UnrollHeuristicOp op) -> std::string {
               llvm_unreachable("heuristic unrolling does not generate a loop");
             })
+            .Case([&](FuseOp op) -> std::string {
+              unsigned int first = 0;
+              unsigned int count = 0;
+              if (op.getFirst() && op.getCount()) {
+                first = op.getFirst().getInt();
+                count = op.getCount().getInt();
+              }
+              unsigned opnum = generator->getOperandNumber();
+              if ((first != 0 && opnum <= first - 1) ||
+                  (count != 0 && opnum >= first + 1))
+                return "canonloop_fuse";
----------------
NouTimbaler wrote:

This checks whether the operand number is the generated loop fusion or it is a loop outside the looprange clause range. If there isn't `first` and `count` attributes or it is in the `first` position then the loop should get the name "fused", otherwise it gets "canonloop_fuse". 

An example to clarify the situation, with `first = 2` and `count = 2`:
`omp.fuse(%canonloop_fuse1, %fused, %canonloop_fuse2) <- (%canonloop_s0, %canonloop_s1, %canonloop_s2, %canonloop_s3)`

I didn't add a check for outside of the range of generated loops since it should only be called on those.
I rewrote the conditional and added a comment on the next commit. I can also add a check for the permitted range for generated loops if it is necessary

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