[PATCH] D85609: Transforms: add ConvergenceControlHeuristic pass

Nicolai Hähnle via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 13 07:58:12 PDT 2021


nhaehnle marked 2 inline comments as done.
nhaehnle added a comment.

Hi @Anastasia, thank you for your comments. I replied inline, but a high-level point upfront is that in many ways, this patch only exists because HLL don't really have well-defined semantics for convergent operations yet. Most of us have a shared mental model of what they should be for most high-level constructs, but intuition breaks down for the trickier corner cases. I made some proposals in the Khronos Memory Model TSG for how useful semantics could be added to HLL, taking the corner cases into account, but on my end all of this is on hold while I'm on leave.



================
Comment at: llvm/lib/Transforms/Utils/ConvergenceControlHeuristic.cpp:15
+///
+///  1. In acyclic code, refer to the nearest dominating convergence token if
+///     one exists.
----------------
Anastasia wrote:
> Can I clarify what do you mean by `refer` here?
> 
> I presume if you only have IR with uncontrolled convergent operation there wouldn't be any tokens to find? Although perhaps this could apply if one has been inserted for another uncontrolled operation previously?
Yes, that's correct.


================
Comment at: llvm/lib/Transforms/Utils/ConvergenceControlHeuristic.cpp:17
+///     one exists.
+///  2. Otherwise, refer to an `entry` intrinsic if the containing function
+///     is convergent, and to an `anchor` intrinsic otherwise.
----------------
Anastasia wrote:
> Right now Clang decorates all function by convergent regardless whether or not they have convergent operations so it seems that if we are to generalize to the new behavior we could just append an entry intrinsic to the entry basic block everywhere?
Yes.


================
Comment at: llvm/lib/Transforms/Utils/ConvergenceControlHeuristic.cpp:18
+///  2. Otherwise, refer to an `entry` intrinsic if the containing function
+///     is convergent, and to an `anchor` intrinsic otherwise.
+///  3. In natural loops, refer to a `loop` heart intrinsic in the loop header.
----------------
Anastasia wrote:
> I would quite like to get an example of HL code that needs an anchor. I am not very clear where it fits at the moment.
It depends on the relevant definitions of the HL languages, which don't exist yet.

If you were to translate an algorithm from CUDA, you'd basically use an anchor wherever `__activemask()` is used.

An example of a piece of code that would leverage it is at https://github.com/nhaehnle/llvm-project/blob/controlflow-wip-v9-pre/llvm/docs/ConvergentOperations.rst#opportunistic-convergent-operations (the `@reserveSpaceInBuffer` example) -- it's not in a HLL, but again, that's because HLL don't really offer these controls yet as inherent language features.


================
Comment at: llvm/lib/Transforms/Utils/ConvergenceControlHeuristic.cpp:20
+///  3. In natural loops, refer to a `loop` heart intrinsic in the loop header.
+///  4. In irreducible cycles, place a heart intrinsic in one of the maximal
+///     dominating blocks inside the cycle, and anchor intrinsics in any others.
----------------
Anastasia wrote:
> Ok, in the frontend we might have very limited information about the full CF structure while parsing.
> 
> 
> Although we could also think of some combined approaches where frontend generates partial information and then the pass completes the rest...
If this is in response to the irreducible cycles, keep in mind that you can only really get those with `goto` in modern languages (or possibly after some transforms have already happened).

I don't know much about Clang in particular, but fong-term, for HLL that have well-defined expected semantics of convergent operations, I expect that it would always be preferable to emit the convergence control information as part of the frontend IR generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85609



More information about the llvm-commits mailing list