[ukernels] Add missing specializations on gfx942/gfx950 and associated e2e tests

[sebvince]

The primary purpose of this PR is to add missing e2e tests to cover all combinations of ukernels. We have different ukernels for static and dynamic shapes, so this PR introduces an option to generate_e2e_matmul_tests.py that allows specifying the dynamicity of m, n, and k.

Since ukernels require specialization to be enabled (see PR #22425), this PR also adds the following missing specializations :

• bf16 on gf942
• f16, bf16, f8 on gfx950.

This will positively affect performance on dynamic shape matmuls without compile-time bounds information. For example :

  !A_size = tensor<?x4096xbf16>
  !B_size = tensor<4096x4096xbf16>
  !C_size = tensor<?x4096xf32>
  
  func.func @matmul(
  %A : !A_size, %B : !B_size) -> !C_size {
  %c0 = arith.constant 0 : index
  %cst = arith.constant 0.000000e+00 : f32
  %m = tensor.dim %A, %c0 : tensor<?x4096xbf16>
  %empty = tensor.empty(%m) : !C_size
  %C = linalg.fill ins(%cst : f32) outs(%empty : !C_size) -> !C_size
  %0 = linalg.matmul 
     indexing_maps = [affine_map<(m, n, k) -> (m, k)>, 
                     affine_map<(m, n, k) -> (n, k)>,// transpose
                     affine_map<(m, n, k) -> (m, n)>]
                     ins(%A, %B : !A_size, !B_size)
                     outs(%C : !C_size) -> !C_size
  return %0 : !C_size
  }

Before PR: Time (ms): 30.831274
After PR: Time (ms): 0.284123

[bjacob]

There is a discrepancy between the PR title which suggests it's a test-only PR, and the PR contents that add new specialization patterns. I'm not competent to review those, so please get another reviewer for that.

[jtuyls]

LGTM. The specialization patterns make sense to me as they are the same as the existing ones, just for different types. If you have any, it would be useful to list experimental result with and without these specialization patterns for the new gfx950 patterns in the PR description.

[sebvince]

LGTM. The specialization patterns make sense to me as they are the same as the existing ones, just for different types. If you have any, it would be useful to list experimental result with and without these specialization patterns for the new gfx950 patterns in the PR description.

After some testing, I found that some f16 & bf16 configurations of pingpong are slower that the default path (independent from this PR). This is due to the fact that current pingpong uses MFMA_F32_16x16x16_F16 instead of MFMA_F32_16x16x32_F16. To keep in mind if we want to enable ukernels by default.
I've created a separate task to fix this : #22457