ssahasra wrote: > Then the point I made up in the comment thread about the semantics is "while > forming the actual mark sequences, we skip all the marks where `waitsOn & > includes == 0`.
That sounds like an implementation detail. What we are really saying is that each stage is an independent sequence of marks, calls to `asyncmark` independently put marks in each of the indicated stages, and calls to `wait.asyncmark` independently ensure that only the specified number of marks remain in each of the indicated stages. > I suppose if we're going to give API stability - declaring that any given > async-tracked intrinsic call will never move from the class we assign to it, > then that's fine, but we'd need to promise that and stick to it. Right. This has to be guaranteed even if internally, we reinterpret the classes. We might combine stages internal, or move them to a different counter, for example. In the programming model, they are merely labels that identify virtual sequences of marks. https://github.com/llvm/llvm-project/pull/220442 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
