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

[Sameer Sahasrabuddhe via Phabricator via llvm-commits]

sameerds marked 7 inline comments as done.
sameerds added inline comments.


================
Comment at: llvm/docs/ConvergentOperations.rst:230
+
+Motivating Examples of Convergence Control
+==========================================
----------------
New section to really bring out the benefit of explicit convergence control. Something that both @jdoerfert and @jsilvanus had asked about, at different points of time.


================
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.
----------------
jsilvanus wrote:
> 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?
Reworded to remove the confusion. The intention is "one or more".


================
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:
> > jsilvanus wrote:
> > > 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.
> > To expand on the above, it probably suffices to add a loop-based example (the one above?) to the list of examples motivating intrinsics, and mention early on that deviating from natural loop-header based convergence is possible and intended, referencing the above new example.
> Ironically, there's now been some discussion that we may be able to simplify this by only allowing loop hearts in natural loop headers.
> 
> They're still required (the example above with the two loops vs. single loop with continue still stands). But yeah, perhaps that could be added to the document.
The spec is now updated to allow a cycle heart only in the header of a natural loop. Thus the notion of an iteration under convergence remains unchanged from the intuitive notion.

Explicit cycle hearts would have allowed the user to specify how "all threads" (for a suitable definition of "all") converge inside an irreducible cycle. But the usefulness of this is rare enough that we can discount it for now.
 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147116