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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> Until then, we do not actually want to pull that convergent op into the loop body. That will produce unnecessary constraints on transforms working with the loop. The convergent op is most definitely on the exit of the loop. And it's useful to keep it there.

This is not obvious to me.  For example, pushing the convergent op out of the loop makes fully unrolling a lot harder: you need to compute a region containing all the uses of the loop token outside the loop, sink any uses of other convergence tokens out of that region, pull all the relevant basic blocks into the loop, then unroll.  (I guess in general, full unroll is actually impossible? As far as I can tell, none of the rules guarantee that "sink any uses of other convergence tokens out of that region" is a legal transform.  Or am I missing some rule that actually ensures that?)

Or consider loop strength reduction: my first impression is that you want LSR to treat the operands of convergent operations that use a loop's token as if they're inside the loop, because the computation of those operands ends up inside the loop in the final assembly.

I guess pushing the blocks out of the loop makes it simpler to sink non-convergent operations out of the loop?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147116