ssahasra wrote: > Not specific to this `.async` case, but regarding the general intrinsic > convention, I don't agree. LLVM intrinsics are not intended to provide a nice > library-like interface, and the backend is not the right place to do the > heavy lifting. There should be only a very limited number of exceptions. > Otherwise, instruction selection would become unmanageable. We have not moved > in that direction so far, and I don't think we ever should.
We have absolutely and most definitely moved in that direction, and we intend to keep doing that. I can't help notice the irony that we are discussing this in the context of `@llvm.amdgcn.asyncmark()` which has absolutely no ISA equivalent, and it is managed entirely by the backend. Then we have the new `@llvm.amdgcn.av` intrinsics that add semantics to ordinary load store instructions. With barriers, there will be more such intrinsics. > Yeah, I don't have an extremely strong opinion on if we put async in the name > of the TDM intrinsics or not, but I do agree there should only be one > intrinsic, not two variants There actually are two variants. There is an existing non-async variant which hides the counter and the compiler magically takes care of it. And now we are exposing an async version. The first one is out of the bag already. We can have a deprecation plan for it separately, but the new one must be named `.async`. This is not about one person's opinion. We have already devised a larger framework here, and `.async` intrinsics is a concept integral to that framework. I continue to be strongly opposed to the `needs change` block that @krzysz00 has placed on this PR. It lacks the larger context. https://github.com/llvm/llvm-project/pull/200775 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
