[Mlir-commits] [mlir] [mlir][scf] Add simple LICM pattern for `scf.while` (PR #76370)

[Mehdi Amini]

joker-eph wrote:

> I understand the reasoning but in practice it is common for compilers to relying on the original program as fall back when a transformation is not obviously a win.

I see this as a very fragile way to design compilers, I would say that if you want to design your compiler that way, don't include canonicalization inside your pass pipeline.

> I don't understand where is the line with regards to canonicalization if we go that route. What kind of transformation would not be a canonicalization then? Would function inlining be a canonicalization for instance? And if not why?

"it's ambiguous" sometimes., but "Inlining" is covered here: https://sunfishcode.github.io/blog/2018/10/22/Canonicalization.html

The way I see it is "how hard is it to reverse a transformation later"? In the case of LICM it is a local transformation and one that a compiler must be able to "undo" (because often the input program will come in both form and the compiler should optimize it!).

Inlining is a global program transformation instead, and we don't know efficiently how to manage this (that is: it's still in the realm of compiler research area, even though there are some implementations around PGO+outlining of common sequence in cold region for example).

> My concern is that this could significantly reduce user control over what transformations are applied as canonicalization 

How is there a "reduction" of control when there is no control already? That is: we don't have canonicalization knobs, almost by design, we just let people either use canonicalization or don't use it.


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