ssahasra wrote: I think I am coming around on the `.async` suffix now. It would be _nice_ if intrinsics that are tracked with `asyncmark` have `.async` in their name, but that's really hard to ensure in the overall development process. The usual flow is that new instructions are expose "as is" without being distracted by potential programming models. It may not be possible to always know in advance what its higher semantics will be, and hence their name cannot be decided up front.
A good example is the tensor load/store intrinsics that already exist. They are raw intrinsics in the sense that the user is entirely responsible for understanding their semantics and using them correctly. Now that they are included in `asyncmark`, nothing fundamentally changed with the intrinsics themselves. This is different from the legacy LDS DMA which got automatic delays first and then we relaxed them in `asyncmark`. If the same had happened with the tensor intrinsics , then _that_ would have been a problem. Hopefully we can push back on that whenever it shows up. So it seems okay to just let the intrinsic be with its current name. `asyncmark` is an _additional_ way for the user to get some help from the compiler in setting up the delays. It's not necessary, and the user is free to use other means like explicit `s_wait_cnt` calls if available. https://github.com/llvm/llvm-project/pull/200775 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
