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

[Renato Golin]

rengolin wrote:

> I haven't thought too deeply about this but I believe the current structure of the `x86Vector` dialect may not scale well as we add more operations. 

Agree. The idea is not to add "all or a lot of operations", but to add enough (3-4) to have a prototype that guide us through a scalable design.

> 1. For targets that do not support certain instructions, such as AVX512, we might want to avoid loading those operations into the dialect registry. Among other benefits, this would prevent us from generating illegal instructions. We could achieve this by creating independent dialects (e.g., `x86.avx512`, `x86.avx2`, `x86.sseXY`).

Conditionally loading operations in a dialect is not something trivial to do, nor it makes sense for cross-compilation, so I'd avoid trying to go there as a first step. I think a simpler step would be to conditionally load entire dialects in response to target (not host) information, but that still need us to have a coherent target description story.

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.

> 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. As soon as we have specialized lowering transforms that can generate LLVM intrinsics directly, most of those instructions become irrelevant.

We do not want to recreate the LLVM pipeline in MLIR.

> It would be great to take some actions on this regard before things get out of control...

There is the intention of design behind this PR, we don't want to just dump instructions here.

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