[Mlir-commits] [mlir] [mlir][x86vector] AVX512-BF16 Dot op (PR #124800)

Diego Caballero llvmlistbot at llvm.org
Thu Jan 30 11:51:43 PST 2025


dcaballe wrote:

> the DLTI work is leading us there, but it's still not required (like LLVM's triple/DL), so we can't rely on that yet. My aim is to make DLTI mandatory like LLVM and then we can start making smarter compiler time and run time selections.

To fill this gap, different downstream project came up with their own way to represent target information and pass that to upstream code in some way. For example, we have some AVX2 specific transformations with an API that allows downstream projects to enable them using target information. I believe designing with that in mind would help transition to whatever we end up adopting without major rework.

>> However, if this conditional registration is not feasible, creating separate dialects for each sub-ISA doesn’t sound terrible to me, esp. if we plan to add a significant number of operations.

> It does sound terrible to me. SSE, AVX, AVX2 and AVX512 have a dozen variations each. NEON and SVE has a few more. And none of those are really there for code generation (like LLVM's intrinsics), but as short-cuts to a handful of LLVM intrinsics.

Well, AVX512 alone has [thousands of intrinsics](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#techs=AVX_512), even when many in that list can be folded together. I think, loading all AVX512 ops vs just the supported subsets could really make a difference. We already have dialects with just a handful of operations so I don't see this being too much different. It's also difficult to know how these operations will be used in the long run. We already have some passes running on SME operations and I wouldn't be surprised if we ended up introducing some transformations/canonicalizations of the AVX2 operations that we generate.

My comment is mostly giving visibility to some concerns that were brought to my attention about the current state of some of these dialects. It's great to hear that there is a plan to improve this. I'll be happy to help to the extent possible :)

https://github.com/llvm/llvm-project/pull/124800


More information about the Mlir-commits mailing list