Removed implicit split-k while moving from conv to gemm

[ravil-mobile]

No description provided.

[ravil-mobile]

Hi @krzysz00 @manupak

I'd like to generate conv_bwd_weight with mfma enabled. Below you can see an example. However, the resulting Op doesn't
have mfma flag set. Im confused whether it is an old bug or it was done on purpose or I am doing something wrong.

rocmlir-gen --conv-config " --operation conv_bwd_weight --arch amdgcn-amd-amdhsa:gfx908:sramecc+:xnack- -mfma=on --in_type fp32 --fil_type fp32 --out_type fp32 --fil_layout GNCHW --in_layout NGCHW --out_layout NGCHW --batchsize 64 --in_channels 1024 --out_channels 1024 --in_h 14 --in_w 14 --out_h 14 --out_w 14 --fil_h 1 --fil_w 1 --dilation_h 1 --dilation_w 1 --conv_stride_h 1 --conv_stride_w 1 --padding_h 0 --padding_w 0 --kernel_name conv --groupsize 1 "
module attributes {mhal.arch = "amdgcn-amd-amdhsa:gfx908:sramecc+:xnack-"} {
  func.func @conv_0(%arg0: memref<1x1024x1024x1x1xf32>, %arg1: memref<64x1x1024x14x14xf32>, %arg2: memref<64x1x1024x14x14xf32>) attributes {kernel = 0 : i32, mhal.arch = "amdgcn-amd-amdhsa:gfx908:sramecc+:xnack-"} {
    rock.conv_bwd_weight(%arg0, %arg1, %arg2) features =  dot|atomic_add {arch = "amdgcn-amd-amdhsa:gfx908:sramecc+:xnack-", dilations = [1 : index, 1 : index], filter_layout = ["g", "k", "c", "0", "1"], input_layout = ["ni", "gi", "ci", "0i", "1i"], numCU = 120 : i32, output_layout = ["no", "go", "ko", "0o", "1o"], padding = [0 : index, 0 : index, 0 : index, 0 : index], strides = [1 : index, 1 : index]} : memref<1x1024x1024x1x1xf32>, memref<64x1x1024x14x14xf32>, memref<64x1x1024x14x14xf32>
    return
  }
}

The absence of mfma flag results in skipping the following branch:

rocMLIR/mlir/lib/Dialect/Rock/Transforms/ConvToGemm.cpp

Lines 1172 to 1175 in 9081f78

	if (ConvOpType::BwdWeight == convOpType &&
	isWrWAtomicKernel(features, dataType, maybeGemmExtraPad.has_value())) {
	return backwardWeightAtomicAdd(cast<ConvBwdWeightOp>(op), b);
	}

I will look at rocmlir-gen regarding why mfma flag gets dropped. I wonder maybe there is a reason for it

[ravil-mobile]

@jerryyin, can you remember what was the reason around !requiredPadding. I mean why we restrict "no padding" to enabled atomic write ops.

rocMLIR/mlir/lib/Dialect/Rock/utility/loweringUtils.cpp

Lines 34 to 39 in 9081f78

	bool mlir::rock::isWrWAtomicKernel(GemmFeatures features, Type dataType,
	bool requiredPadding) {
	return isAccel(features) &&
	bitEnumContainsAll(features, GemmFeatures::atomic_add) &&
	(dataType.isF32() || dataType.isF16()) && !requiredPadding;
	}

I seems to me this part became some kind of legacy code