Fix matmul incorrect results when k dim for CTA tile is a multiple of 16

[rdspring1]

This PR fixes the incorrect results issue when k dimension for CTA tile is a multiple of getK(mma_macro).

Why?

• In scheduleMmaResults, we need to split the k reduction by getK(mma_macro). A serial reduction will add the results from wgmma along k-dimension.

Details

• Modified transformLikeMmaOutput function to not be used in scheduleMmaResults.
• Add HSH_TN_UseScheduler test

Performance Results

HSH_TN_UseScheduler - 1.038 - Basically a tie

CTA tile is M=64, K=256, K=32

 Time (%)  Total Time (ns)  Instances  Avg (ns)  Med (ns)  Min (ns)  Max (ns)  StdDev (ns)                                                  Name                                                
 --------  ---------------  ---------  --------  --------  --------  --------  -----------  ----------------------------------------------------------------------------------------------------
     27.5           466137          1  466137.0  466137.0    466137    466137          0.0  nvjet_hsh_128x256_64x4_2x1_v_bz_coopA_TNN                                                           
     26.5           448985          1  448985.0  448985.0    448985    448985          0.0  <unnamed>::nvfuser_none_f0_c0_r0_g0(<unnamed>::Tensor<<unnamed>::__half, (int)3, (int)3>, <unnamed>…

HSH_NT_UseScheduler - 0.9155

CTA tile is M=64, K=256, K=32

 Time (%)  Total Time (ns)  Instances  Avg (ns)  Med (ns)  Min (ns)  Max (ns)  StdDev (ns)                                                  Name                                                
 --------  ---------------  ---------  --------  --------  --------  --------  -----------  ----------------------------------------------------------------------------------------------------
     27.7           468281          1  468281.0  468281.0    468281    468281          0.0  <unnamed>::nvfuser_none_f0_c0_r0_g0(<unnamed>::Tensor<<unnamed>::__half, (int)3, (int)3>, <unnamed>…
     25.4           428729          1  428729.0  428729.0    428729    428729          0.0  nvjet_hsh_128x256_64x4_2x1_v_bz_coopA_NTN   

[rdspring1]

!test

[jacobhinkle]

👀

[jacobhinkle]

Good catch, although I think it currently has no meaning until we start handling epilogue inputs with supported vec size.

[rdspring1]

!test

[rdspring1]

!test