[PATCH] D147116: [RFC] Introduce convergence control intrinsics

Jannik Silvanus via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 14 05:44:34 PDT 2023


jsilvanus added inline comments.


================
Comment at: llvm/docs/ConvergentOperations.rst:574
+   instances of ``D``, and,
+2. There is an *n* such that both threads execute ``U`` for the *n*'th time
+   with that token value.
----------------
Maybe mention that `n` is an integer, so

There is an integer *n* such that [..]


================
Comment at: llvm/docs/ConvergentOperations.rst:725-727
+for cycles instead of closed paths. Briefly, if a closed path does not
+satisfy any of the above properties, then there is always a cycle that
+also does not satisfy the same property.
----------------
Maybe "does not satisfy" -> "violates"?
In the current form, there is a ambiguity in whether all properties are violated, or just a single one.
I assume a single one is intended?


================
Comment at: llvm/docs/ConvergentOperations.rst:829-830
+other thread *after* it reaches the heart, thus preventing them from being
+converged with each other. Thus, the heart of a cycle changes the notion of an
+"iteration" in terms of convergence.
+
----------------
I think this property should be communicated more prominently.

Per my understanding, loops in reducible control flow have unique headers, which give rise to a "natural" convergence (implicit maximal convergence?) by counting executions of the header, and considering those converged if the counter agrees.
For irreducible control flow, there are no unique headers, instead there is an ambiguity caused by the dependency on a choice of a cycle hierarchy (and their headers).

Explicit convergence control intrinsincs eliminate this ambiguity by allowing to explicitly define loop hearts. But for reducible control flow, if loop hearts are not placed at loop headers, then the notion of convergence may be different. I believe this is what these lines refer to. For example, in the example in llvm/docs/convergence-heart.png, removing the edge from D to R makes the CFG reducible, but iteration counts at R might be different from iteration counts at H, due to the shortcut from H to L.

Is that intentional, a "neutral" side-effect of the model, or a side-effect of the model that we would want to eliminate but cannot easily?
In any case, I think we should discuss this more explicitly. Also, an example somewhere suggests to construct explicit control intrinsics by putting hearts into loop headers, maybe we can mention there that this ensures that the two notions of convergence agree, because the imaginary counters do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147116



More information about the llvm-commits mailing list