[PATCH] D68994: [RFC] Redefine `convergent` in terms of dynamic instances

[Marcello Maggioni via Phabricator via llvm-commits]

kariddi added a comment.

What is the expectiation of lowering of a loop like the one you mentioned above?

int divergent_key = ...;
int v = ...;
int sum;

  for (;;;) {
    tok = @llvm.convergence.anchor()
    int uniform_key = readfirstlane(divergent_key);
    if (uniform_key == divergent_key) {
      sum = subgroup_reduce_add(v);
      @llvm.convergence.point(tok)
      break;
    }
  }

In particular the expectation of lowering in LLVM-IR is typically that the block with the "break" is an exit block and as such is typically moved outside of the loop (when the threads are reconverted). Is the expectation to have LLVM.CONVERGENCE.POINT to be lowered to the backends with a pseudo instruction similar to DBG_VALUE (and then be ignored by regalloc and such) up to the point that final control-flow block ordering is defined so that the execution of the "unconverged" part of the exit block is lowered so that is executed inside the loop instead of outside?



================
Comment at: llvm/docs/DynamicInstances.rst:61
+
+1. Every instruction in an LLVM IR function has zero or more dynamic instances.
+
----------------
While I like the idea of formalizing the whole "Dynamic Instances" concept I wonder if it could be explained in a more intuitive way as well in order to make the understanding of the formal definitions easier by approaching  them with an intuition already of what they are. 


================
Comment at: llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1474
+      // with which the convergent operation communicates.
+      if (C->isConvergent())
+        return false;
----------------
Is this the only change in SimplifyCFG we would have to do?

What about FoldBranchToCommonDest() ? It seems to be hoisting instructions into the predecessors , but it just checks for the Speculable attribute (through isSafeToSpeculativelyExecute()) and seem to ignore the Convergent attribute.

In general how much the new behavior has been vetted around LLVM passes with respect respecting hoisting or changes in thread execution mask?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68994/new/

https://reviews.llvm.org/D68994