[mlir][gpu] Reduce operations diverged from vector combining kinds

[kuhar]

The gpu dialect provides a number of available reduction kinds (gpu::AllReduceOperation) available in ops, gpu.all_reduce and gpu.subgroup_reduce. Currently, these reduction kinds are: add, and, max, min, mul, or, xor.

The min and max reductions are ambiguous for integer (e.g., signed min != unsinged min) and float types (NaN handling). I think these should be aligned with vector reduction kinds that resolve these ambiguities:

add/mul/minsi/minui/maxsi/maxui/and/or/xor for integers,
and add/mul/minf/maxf/minimumf/maximumf for floats.

Because the gpu dialect does not depend on the vector dialect, the most practical choice would be to copy over the min/max kinds from the vector dialect.

Have I missed something?

[llvmbot]

@llvm/issue-subscribers-mlir-gpu

Author: Jakub Kuderski (kuhar)

The gpu dialect provides a number of available reduction kinds (`gpu::AllReduceOperation`) available in ops, `gpu.all_reduce` and `gpu.subgroup_reduce`. Currently, these reduction kinds are: add, and, max, min, mul, or, xor.

The min and max reductions are ambiguous for integer (e.g., signed min != unsinged min) and float types (NaN handling). I think these should be aligned with vector reduction kinds that resolve these ambiguities:
> add/mul/minsi/minui/maxsi/maxui/and/or/xor for integers,
> and add/mul/minf/maxf/minimumf/maximumf for floats.

because the gpu dialect does not depend on the vector dialect, the most practical choice would be to copy over the min/max kinds from the vector dialect.

Have I missed something?

[kuhar]

One other difference is that vector reductions can also have fast math flags (#66905), which are absent from gpu reductions.

cc: @antiagainst @nicolasvasilache @unterumarmung @dcaballe @joker-eph

[nicolasvasilache]

Makes sense to me, is there a way to write these in one common place and just include them in the proper Tablegen file?

[antiagainst]

Maybe put in a new include/mlir/Dialect/Utils/ReductionCombinerUtils.td file or something?

[kuhar]

Makes sense to me, is there a way to write these in one common place and just include them in the proper Tablegen file?

Maybe put in a new include/mlir/Dialect/Utils/ReductionCombinerUtils.td file or something?

Yeah this also makes sense, but I'd rather do it in two stages: (1) update gpu reductions, (2) introduce a common definition.

[antiagainst]

Sequencing sounds good to me!

[dcaballe]

Makes sense to me, is there a way to write these in one common place and just include them in the proper Tablegen file?

• 1 to having a common place.

I think I saw another replication of this recently but I can't remember... Perhaps on the SVE/SME side? (@c-rhodes, @MacDue)?

[kuhar]

I found one more enum like that in NVVM:

namespace NVVM {
// NVVM redux kind
enum class ReduxKind : uint32_t {
  ADD = 1,
  AND = 2,
  MAX = 3,
  MIN = 4,
  OR = 5,
  UMAX = 6,
  UMIN = 7,
  XOR = 8,
};

although I do not intend to touch this one, as it seems backend-specific.

[c-rhodes]

Makes sense to me, is there a way to write these in one common place and just include them in the proper Tablegen file?

* 1 to having a common place.

I think I saw another replication of this recently but I can't remember... Perhaps on the SVE/SME side? (@c-rhodes, @MacDue)?

@MacDue added one to ArmSME for outerproducts recently in #69604:

llvm-project/mlir/include/mlir/Dialect/ArmSME/IR/ArmSMEOps.td

Lines 130 to 143 in f8986df

	/// An attribute that specifies the layout of a tile slice in a tile.
	def ArmSME_TileSliceLayoutAttr : EnumAttr<ArmSME_Dialect, TileSliceLayout,
	"layout"> {
	let assemblyFormat = "`<` $value `>`";
	let defaultValue = "TileSliceLayout::Horizontal";
	}
	def CombiningKind : I32EnumAttr<"CombiningKind", "Kind of combining function", [
	I32EnumAttrCase<"Add", 0, "add">,
	I32EnumAttrCase<"Sub", 1, "sub">,
	]> {
	let cppNamespace = "::mlir::arm_sme";
	let genSpecializedAttr = 0;
	}

but it only supports add/sub.

[grypp]

I found one more enum like that in NVVM:

namespace NVVM {

// NVVM redux kind

enum class ReduxKind : uint32_t {

  ADD = 1,

  AND = 2,

  MAX = 3,

  MIN = 4,

  OR = 5,

  UMAX = 6,

  UMIN = 7,

  XOR = 8,

};

although I do not intend to touch this one, as it seems backend-specific.

This enum keeps the supported reduction types for 'redux' instruction in PTX. You're right this backend specific, I think let's keep it this as it is.