[PATCH] D103958: [WIP] Support MustControl conditional control attribute

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> Defining the value used to establish a control dependency, e.g. the load later writes depend on (kernel only defines writes to be ctrl-dependently ordered).

`[[mustcontrol]]` also has this problem.

At the LLVM IR level, if just want to split the load from the control dependency intrinsic, we could define a special kind of load that produces a LLVM IR "token".  The control dependency intrinsic then takes the token as an operand, and optimizations understand that they aren't allowed to touch the token.

The problem at that point is, how does clang emit LLVM IR?  It would have to do some sort of dataflow analysis to connect the load to the control dependency.  And we'd need to define rules for what sort of data/control flow are allowed.  That's not impossible, but it's complicated.

> 2. Defining later ops that are control-dependent. With an expression like the __builtin, this could be any operation after, or it becomes too hard to define:

I don't think this is a problem we need to solve.  If the user sticks the builtin in some weird location that doesn't have a branch immediately following it, that's fine.  Any branch that depends on a value can enforce a control dependency, so in general, we just insert a no-op branch at the point of the call to the builtin.  Like I mentioned before, we can think of removing that no-op branch as an optimization.

----

Whatever we end up doing, I really don't want to mark up LLVM IR branches.  I don't want to add more constraints to CFG transforms at the LLVM IR level.  The rules are already hard to understand; I don't want to add more weird edge cases.  And I don't think it's necessary here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103958