[llvm] [AMDGPU] Enable WMMA256bInsts + Wave32 for gfx1200/gfx1201 + SISchedule fix + TargetParser gfx1200 propagation (PR #202093)

[via llvm-commits]

clearnature wrote:




> @clearnature Whoops, forgot to submit my comments from yesterday.
> 
> I'm just a random asshole on github, who has nothing to do with the LLVM project, and I will be blunt: This whole PR looks AI hallucinated.
> 
> 1. Your proposed code changes would break support for quite a few IP blocks, specifically anything gfx117X and gfx125x, though for gfx120x they would cause the hardware to use unnecessary extra vgprs.
> 2. You refer to nonexistent files in your own personal repository with the "reverse engineering tool" to justify your absolutely ludicrous performance claims that are **5x higher** than what the hardware is physically capable of outputting.
> 3. Your claimed execution latencies are all wrong, as you could see if you looked at something like the [Matrix Instruction calculator](https://github.com/ROCm/amd_matrix_instruction_calculator).
> 4. You refer to nonexistent commits/LOCs in AMDs upstream repository, a clear sign that whatever LLM you used to compose this hallucinated them into existence.
> 
> I think that's most of it.
*******************************************
Thanks for your feedback. My technical expertise has its limits, so the final outcome relies on the maintainers' review. Regarding your doubts about the scheduling latency table and performance metrics: this research concerns microarchitecture and kernel performance, and I have already submitted a pull request (PR) to AMD. There is no need to argue over the facts; I own the actual RX 9060 XT 16GB hardware. I reverse-engineered the microarchitecture and uncovered some interesting data—feel free to check the ROCm PR, as they are waiting on this LLVM update for support. No amount of skepticism outweighs the fact that I have the actual hardware for testing; the difference between theory and real-world testing is obvious. AMD's consumer-facing engineers are likely very busy. They did comment on the microarchitecture—it was interesting—though I initially posted it in the wrong place. AMD's internal engineers released an update in February, but the LLVM AMD branch only received partial updates on June 7th—typical of corporate timelines and workflows, I suppose. The hardware has been out for nearly six months, yet software support remains incomplete; consumers are essentially acting as guinea pigs for new hardware. Then again, I’m the one who wanted to use better sparse matrix capabilities. Even though the software is open-source, the maintenance work really ought to be handled by AMD.

https://github.com/llvm/llvm-project/pull/202093