[Mlir-commits] [mlir] [mlir][Vector] Move vector.extract canonicalizers for DenseElementsAttr to folders (PR #127995)

Kunwar Grover llvmlistbot at llvm.org
Tue Feb 25 08:55:15 PST 2025


Groverkss wrote:

> I'm not sure if I agree with this generalization either. For example, we'd expect folders to be invoked much more frequently in the compilation pipeline (and often sometimes without opt-out like in dialect conversion), so I'd be much more wary of spending compilation time on folds that are either costly or very unlikely to apply. Downstream compilers can decide how often to run canon patterns based on the amount of compilation time budget.

Costly transformations shouldn't be canonicalizations at all (from the docs):

```
Pattens with expensive running time (i.e. have O(n) complexity) or complicated
cost models don’t belong to canonicalization: since the algorithm is executed
iteratively until fixed-point we want patterns that execute quickly (in
particular their matching phase).
```

Regarding "very unlikely to apply", I'm not sure without benchmarking a transformation it's really easy to say if the cost of folding is big. If the cost of folding is infact significant even after not having expensive transformations running as folders, then folding should just be disabled in the rewrite driver and added selectively as patterns (i.e. call the folder as a pattern). I've never heard of folding being a significant cause of compile-time regressions. 

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


More information about the Mlir-commits mailing list