[flang-commits] [flang] [llvm] [mlir] [flang][OpenMP] Support the FULL clause on the UNROLL construct (PR #214115)

[Sairudra More via flang-commits]

================
@@ -0,0 +1,26 @@
+// Test lowering of omp.unroll_full applied to the inner loop of a nest
+// RUN: mlir-translate -mlir-to-llvmir %s | FileCheck %s
+
+llvm.func @unroll_full_inner_loop(%baseptr: !llvm.ptr, %tc1: i32, %tc2: i32) -> () {
+  %outer_cli = omp.new_cli
+  %inner_cli = omp.new_cli
+  omp.canonical_loop(%outer_cli) %iv1 : i32 in range(%tc1) {
+    omp.canonical_loop(%inner_cli) %iv2 : i32 in range(%tc2) {
+      %ptr = llvm.getelementptr inbounds %baseptr[%iv2] : (!llvm.ptr, i32) -> !llvm.ptr, f32
+      %val = llvm.mlir.constant(42.0 : f32) : f32
+      llvm.store %val, %ptr : f32, !llvm.ptr
+      omp.terminator
+    }
+    omp.terminator
+  }
+  omp.unroll_full(%inner_cli)
+  llvm.return
+}
+
+// Only the inner loop carries the full-unroll metadata; the outer loop is
+// untouched.
+// CHECK-LABEL: define void @unroll_full_inner_loop(
+// CHECK: !llvm.loop ![[MD:[0-9]+]]
----------------
Saieiei wrote:

Could this test pin the metadata to the inner loop's backedge and verify that the outer loop does not carry `llvm.loop.unroll.full`? As written, it only proves that some loop has the full-unroll metadata, so it could still pass if the metadata were accidentally attached to the outer loop.

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