[llvm] [SPIR-V] Add llvm.loop.unroll metadata lowering (PR #132062)

[Dmitry Sidorov via llvm-commits]

================
@@ -611,6 +611,40 @@ class SPIRVStructurizer : public FunctionPass {
       auto MergeAddress = BlockAddress::get(Merge->getParent(), Merge);
       auto ContinueAddress = BlockAddress::get(Continue->getParent(), Continue);
       SmallVector<Value *, 2> Args = {MergeAddress, ContinueAddress};
+      unsigned LC = SPIRV::LoopControl::None;
+      // Currently used only to store PartialCount value. Later when other
+      // LoopControls are added - this map should be sorted before making
+      // them loop_merge operands to satisfy 3.23. Loop Control requirements.
+      std::vector<std::pair<unsigned, unsigned>> MaskToValueMap;
+      if (getBooleanLoopAttribute(L, "llvm.loop.unroll.disable")) {
+        LC |= SPIRV::LoopControl::DontUnroll;
+      } else {
+        if (getBooleanLoopAttribute(L, "llvm.loop.unroll.enable")) {
+          LC |= SPIRV::LoopControl::Unroll;
+        }
+        std::optional<int> Count =
+            getOptionalIntLoopAttribute(L, "llvm.loop.unroll.count");
+        if (Count && Count != 1) {
+          LC |= SPIRV::LoopControl::PartialCount;
+          MaskToValueMap.emplace_back(
+              std::make_pair(SPIRV::LoopControl::PartialCount, *Count));
+        }
+        if (getBooleanLoopAttribute(L, "llvm.loop.unroll.full")) {
+          // llvm.loop.unroll.full doesn't have a direct counterpart in SPIR-V,
+          // the closest thing we can do is to add Unroll mask and if the trip
+          // count is not known at compile time - either disable unrolling by
+          // setting PartialCount to 1 or reuse already available PartialCount.
+          LC |= SPIRV::LoopControl::Unroll;
+          if ((LC & SPIRV::LoopControl::PartialCount) == 0) {
+            LC |= SPIRV::LoopControl::PartialCount;
+            MaskToValueMap.emplace_back(
+                std::make_pair(SPIRV::LoopControl::PartialCount, 1));
+          }
----------------
MrSidims wrote:

The logic was, that `llvm.loop.unroll.enable` implies, that if the trip count is not known at compile time, then the loop can still be partial unrolled. Meanwhile `llvm.loop.unroll.full` just doesn't hints any unrolling, if trip count is not known at compile time. So (as SPIR-V spec doesn't distinguish between Unroll(enable) and Unroll(full)) `Unroll + PartialCount(1)` would mean to the backend: "please evaluate if it's possible to unroll the loop, and if not - do nothing with it". And I followed this logic long ago in https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/1664 .

Now, after some thinking, this logic seem incorrect to me. As if optimizer faces `Unroll + PartialCount(1)` loop controls, it should actually pick conservative approach and don't even try to unroll the loop. So I've removed this logic from the PR.

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