[clang] [llvm] [AMDGPU] Add async variants of tensor load/store LDS intrinsics. (PR #200775)

[Sameer Sahasrabuddhe via cfe-commits]

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