melver added a comment. In D103958#2811246 <https://reviews.llvm.org/D103958#2811246>, @efriedma wrote:
>> 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. Thanks, all good points. The main thing was that we though it'd be much harder to get a `__builtin_control_dependency()` right (GCC devs didn't like it). If you think that `__builtin_control_dependency()` is the cleaner design, then let's try that! From a user's point-of-view, it certainly is more flexible if we can get it! I'll abandon this change. Thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103958/new/ https://reviews.llvm.org/D103958 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
