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

[Jannik Silvanus via Phabricator via llvm-commits]

jsilvanus added inline comments.


================
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.
+
----------------
nhaehnle wrote:
> jsilvanus wrote:
> > 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.
> I'd say it's somewhere between intentional and a neutral side-effect. It certainly allows for some interesting experiments.
> 
> By the way, the whole loop intrinsic business isn't only about eliminating ambiguity for irreducible loops. Consider:
> ```
>   do {
>     do {
>       a();
>     } while (conda);
>     b();
>   } while (condb);
> 
>   // vs.
>   do {
>     a();
>     if (conda)
>       continue;
>     b();
>   } while (condb);
> ```
> Assuming that `conda` implies `condb`, these two loops are semantically identical from a single-threaded perspective and could easily result in identical CFGs. But the "intuitively expected" convergence behavior is very different.
> 
> Convergence control allows us to explicitly encode in the IR which of the two intuitive behaviors are expected. (And for the first version of the loop, this would result in two nested loops in the CFG that cannot be collapsed into a single one because the loop intrinsics are "in the way".)
Thanks for the background and the example, that definitely helps.

I still feel this should be stated more explicitly, possibly quite at the beginning when introducing these new concepts?

We motivate the use of convergent operations in great detail, but motivate only very briefly why we need to control it explicitly.
An example where naive loop-header-based convergence is not intended would be helpful for that.
Also, generalizing this example, the fact that explicit control intrinsics allow to change the structure of nested loops while preserving convergence semantics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147116