Enable ukernels on remaining aarch64 targets

[bjacob]

As newer aarch64 targets increasingly support SVE and SME, this clause was preventing ukernels from being used in cases where they do speed things up. The reason why this logic was out of place here is that what it controls here is the enablement of ukernels, which are a detail of lowering an already tiled workload. If we wanted to use SVE with a variable vector length, or with a fixed vector length different from NEON's 128bit, that decision needed to be made earlier; conversely, if the workload at this point already has the right shaped to be matched to a NEON ukernel, then SVE is not relevant to it anymore.

FYI @ziereis , this results in substantially faster code in your test case from #19873.

[hanhanW]

cc @banach-space you're able to disable the ukernels with --iree-llvmcpu-enable-ukernels=none flag. The decision of whether using data-tiling is in

iree/compiler/src/iree/compiler/Codegen/ExternalInterfaces/CPUEncodingExternalModels.cpp

Lines 389 to 394 in 82255c7

	static SmallVector<TileMxNxK> enumerateMatmulTileArm64(TypeRange elementTypes,
	DictionaryAttr config) {
	// Data-tiling for SVE is not implemented yet.
	if (hasFeature(config, "+sve") || hasFeature(config, "+sve2")) {
	return {};
	}

[banach-space]

cc @banach-space you're able to disable the ukernels with --iree-llvmcpu-enable-ukernels=none flag. The decision of whether using data-tiling is in

iree/compiler/src/iree/compiler/Codegen/ExternalInterfaces/CPUEncodingExternalModels.cpp

Lines 389 to 394 in 82255c7

	static SmallVector<TileMxNxK> enumerateMatmulTileArm64(TypeRange elementTypes,
	DictionaryAttr config) {
	// Data-tiling for SVE is not implemented yet.
	if (hasFeature(config, "+sve") || hasFeature(config, "+sve2")) {
	return {};
	}

Thanks for the ping 🙏🏻