[Rock][NonAccel] Vectorize the C writeback along gemmM for M-contiguous outputs

[pfultz2]

Motivation

NHWC f32 convolutions on gfx1201 run ~7-9% slower than NCHW even with
exhaustive tuning (e.g. 512→1536 k=2 pad=1 @32x32: 408us vs 385us). These use
the non-accelerated GEMM path (no f32 WMMA), where the C writeback iterates
with n_thread innermost unconditionally. For NHWC outputs the
memory-contiguous dimension is gemmM (k innermost), so every thread issues
scalar b32 stores scattered 6KB apart across lanes. The same problem applies
to any --transC-style GEMM: forcing an M-contiguous C through this path
costs ~10% (450us → 404us on a 1536x1089x2048 f32 GEMM once fixed).

Additionally, the outputSwizzle tuning parameter (9th field of v3 perf
configs) was silently ignored on the non-accel path: the OutputSwizzle pass
reads it from a func attribute that only the accel and attention lowerings set.

Technical Details

• In GridwiseGemmRewritePattern (GridwiseGemmToBlockwise.cpp), query
  getMaxVectorization on the C operand for gemmM and gemmN. When M
  vectorizes better than N (storeMFast):
  • Keep the accumulator n-major in registers: view the flat C register
    buffer as [n, m] and hand the blockwise gemm a transposed [m, n] view
    of it, so the register order matches the new store order.
  • Emit the writeback's iter merge as
    {n_repeat, n_thread, m_repeat, m_thread} instead of
    {m_repeat, m_thread, n_repeat, n_thread}, putting m_thread innermost
    so the threadwise write vectorizes along gemmM (b64/b128 stores, with
    m_cuwave lanes forming contiguous 32-64B clusters).
• When N vectorizes at least as well as M, codegen is unchanged; NCHW kernels
  produce bit-identical ISA (their output vectorizes in neither dimension).
• Set the outputSwizzle func attribute from GeneralGemmParams in the
  non-accel lowering, matching the accel/attention paths. Default
  (2 = heuristic) behavior is unchanged; this only makes the existing knob
  functional.

Test Plan

Test Result

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.