[PATCH] D85603: IR: Add convergence control operand bundle and intrinsics

Nicolai Hähnle via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 7 07:49:23 PDT 2020


nhaehnle added inline comments.


================
Comment at: llvm/docs/ConvergentOperations.rst:339-343
+1. Let U be a static controlled convergent operation other than
+   :ref:`llvm.experimental.convergence.loop <llvm.experimental.convergence.loop>`
+   whose convergence token is produced by an instruction D. Two threads
+   executing U execute the same dynamic instance of U if and only if they
+   obtained the token value from the same dynamic instance of D.
----------------
simoll wrote:
> nhaehnle wrote:
> > simoll wrote:
> > > Should suffice to say that they two threads will execute the same instance if they see the same token value.
> > > Above you stated that the token value represents the dynamic instance of the defining instruction.
> > No, this is explicitly not sufficient. You can have:
> > ```
> >   %tok = call token @llvm.experimental.convergence.anchor()
> >   br i1 %cc, label %then, label %next
> > 
> > then:
> >   call void @convergent_op() [ "convergencectrl"(token %tok) ]
> >   br label %next
> > 
> > next:
> > ```
> You mean control could deviate threads? But those threads won't even reach the convergent instruction and only among those that do those that have the same runtime token value will execute it as a pack.
Ah, I misread your earlier comment. Yes, though there's a question of whether the different threads actually see the same value, or whether they see different values that happen to refer to the same dynamic instance of the defining instruction. One may want to think of the token value as a handle to some control structure that refers to a dynamic instance and also holds a loop counter for the loop heart intrinsic. I don't think it really matters much either way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85603



More information about the llvm-commits mailing list