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

[Marcello Maggioni via Phabricator via llvm-commits]

kariddi added a comment.

Thanks for the answers! It was about time somebody tackled this problem in LLVM :)

A couple extra questions I have:

1. Changing the convergent attribute from being sink prevention only to both sink/hoist prevention (which should impact CSE as well I believe even if I didn't see any change on that regard) would have some performance impact. Considering there's another proposal with respect to make convergent the default from Matt, how do we see this impacting performance. Should we have two (or more?) attributes instead? For example quad-scoped texture operations don't really care about being hoisted/cse'd up, but they care about being sinked.

2. llvm.convergence.join is marked IntNoMem. Its not clear to me how is it gonna survive instcombine considering that is not emitting any value , so nothing is in place to keep it alive. What's the mechanism that's keeping it around?

3. Is there a plan on how we are gonna figure out all the optimizations that need to be updated and in particular, how are we gonna make sure new optimizations (probably written with single threaded in mind) are not gonna break our invariants. (Basically how do we make everybody aware this exists and make them think about it). In particular there could be classes of optimizations that work uniquely on CFG that now would maybe have to look "inside the blocks" before transforming because they need to make sure there's no convergent instruction/call while operating over the blocks they are considering.



================
Comment at: llvm/docs/DynamicInstances.rst:61
+
+1. Every instruction in an LLVM IR function has zero or more dynamic instances.
+
----------------
nhaehnle wrote:
> kariddi wrote:
> > 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. 
> I don't think we can get away without a formal description, but I'm not against having some more illustrative examples. Do you have anything in mind?
Yep, my suggestion was about adding a preamble before the formal definition that explains in more "earthly" terms what the concept is before jumping to the formal definition. Certainly not replacing the formal definition. I really like the fact that you added it in there!
Maybe commonly known concepts like warps, threads in a warp and divergence could be used to that effect. If I understood correctly the concept "Dynamic instance" is the execution of an instruction by a certain group of threads and the same instruction can be executed by different group of threads at different point in time. (Please correct me if I misunderstood) . If its something like this it could be more intuitively be placed before the formal definition. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68994