[Mlir-commits] [mlir] [MLIR][Linalg] Add specialization for linalg.broadcast (PR #104684)

[Renato Golin]

================
@@ -22,13 +22,32 @@
 #include "llvm/ADT/SmallBitVector.h"
 #include "llvm/ADT/SmallVector.h"
 #include <algorithm>
+#include <numeric>
 
 using namespace mlir;
 using namespace mlir::linalg;
 
 /// Include the definitions of the copy operation interface.
 #include "mlir/Dialect/Linalg/IR/LinalgInterfaces.cpp.inc"
 
+namespace {
+/// Check linalg generic with single input output has
+/// body that is just a yield op yielding input value.
+static bool bodyIsJustYieldOp(GenericOp genericOp) {
----------------
rengolin wrote:

> Also, what is going to happen to ContractionOps and existing generic-to-named OpInterfaces which are already written out. Port all of them?

Eventually yes. But I wouldn't try to push that as a blocker.

> I want to make the generic-to-named more complete (e.g. convolution, pooling ... is missing). I dont see how another approach will make it faster.

It's not about faster, it's about avoiding the bloat that this conversion is already creating. We had the exact same problem that we had dozens and dozens of helper functions. I think there's already prior art in MLIR (where we took it from), so if you want to use that, probably better.

> The main challenge in generic-to-named is distilling and abstracting semantics

Yup, and that is currently spread across functions that are basically identical to each other except one thing.

If you can at least parametrize / templatize the existing calls, that would already help a lot. `isCopy`, `isFill`, `isBroadcast` all call the same checks, over and over.

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